Negotiation Process
When an IPSec policy
is Assigned (made active) and the IPSec service is running each network
communication, both incoming and outgoing policies are evaluated to see
whether they meet the conditions specified in the IPSec policy. If a
condition match is made—for example, an outgoing Simple Mail Transfer
Protocol (SMTP) communication that matches a filter—the filter is
triggered and the filter action occurs. If the filter action is Block or
Allow, that is what occurs, but if it is Negotiate, a number of
processing steps must follow.
Processing can be
divided into Phase I, or Main Mode negotiation, and Phase II, or Quick
Mode negotiation. For purposes of this discussion, we’ll use the
computer names Red and Blue. Figure 1 illustrates a simplification of the process. A more detailed explanation follows.
A request has triggered the IPSec filter.
Main Mode (the master key and the IKE Security Association [SA] are established) negotiations begin and complete.
The negation of an SA pair (inbound and outbound) for application packet transfers completes.
The application packets are passed by the Transmission Control Protocol/Internet Protocol (TCP/IP) driver to the IPSec driver.
The IPSec driver formats and cryptographically processes the packets and sends them using the outbound SA.
Secure packets cross the network.
The
IPSec driver on the receiving computer cryptographically processes the
packets arriving on the inbound SA, formats them as normal IP packets,
and then passes them to the TCP/IP driver.
The TCP/IP driver passes the packets to the application.
See Also
IKE is the algorithm by which the first secure Security Association, or SA (a secure channel), is negotiated. It includes authentication, the calculation of the master key
(the key from which all session keys are derived), and the
establishment of the IKE SA. The most interesting part of IKE is that
the master key is calculated separately on each computer. The same key
is derived and is never transported across the network. A complex
mathematical process is used. You can read more about IKE negotiation
and this process at RFC 2409: http://www.ietf.org/rfc/rfc2409.txt. |
The following steps explain the Main Mode process in detail:
1. | A communication packet is sent from Computer Red to Computer Blue.
|
2. | The
IPSec driver on Computer Red checks its outbound IP filter lists and
concludes that the packets match a filter and the filter action is
Negotiate—the packets need to be secured.
|
3. | The IPSec driver notifies IKE to begin negotiations.
|
4. | Computer
Red checks its policy for the Main Mode settings (authentication,
Diffie-Hellman group, encryption, and integrity) to propose to Computer
Blue.
|
5. | Computer Red sends the first IKE message using UDP source port 500 and destination port 500.
|
6. | Computer
Blue receives the IKE Main Mode message that is requesting secure
negotiation. It uses the source IP address and destination IP address of
the packet to look up its own IKE filter. The IKE filter provides the
security requirements for communications from Computer Red.
|
7. | If
the security settings proposed by Computer Red are acceptable to
Computer Blue, negotiation of the Main Mode or IKE SA begins.
|
8. | Both
computers negotiate options, exchange identities and authenticate them,
and generate a master key. The IKE SA is established.
|
Note
Microsoft’s
implementation of IPSec supports offloading of encryption to network
interface cards (NICs) that can perform encryption. Not every NIC can
support offloaded encryption, but several are specifically designed to
do so. Use of such cards can improve the performance on servers where
many possible IPSec connections can be frequently used. You can read
more about one of these special NICs at http://www.3com.com/products/proddatasheet/datasheet/3c905b_fx.pdf. |
The following steps explain the Quick Mode process in detail:
1. | Computer
Red performs an IKE mode policy lookup to determine the full policy.
(IKE negotiation does not factor in the port number, IP address, or
other factors that might have triggered the negotiation.)
|
2. | Computer Red proposes its options (cryptographic as well as frequency of key changes, and so on) and filters to Computer Blue.
|
3. | Computer
Blue does its own IKE mode policy lookup. If it finds a match with that
proposed by Computer Red, it completes the Quick Mode negotiation to
create a pair of IPSec SAs.
|
4. | One
SA is outbound, the other is inbound, each SA is identified by a
Security Parameters Index (SPI), and the SPI is part of the header of
each packet sent. Computer Red’s IPSec driver uses the outbound SA and
signs, and, if specified, encrypts the packets. If hardware offload of
IPSec cryptographic functions is supported by the network card, the
IPSec driver just formats the packets; otherwise, it formats and
cryptographically processes the packets.
|
5. | The IPSec driver passes the packets to the network adapter driver.
|
6. | The network adapter driver puts the datagrams on the network.
|
7. | The network adapter at Computer Blue receives the (encrypted) packets from the network.
|
8. | The
SPI is used to find the corresponding SA. (This SA has the associated
cryptographic key necessary to decrypt and process the packets.)
|
9. | If
the network adapter is specifically designed to perform encryption and
therefore can decrypt the packets, it will do so. It passes the packets
to the IPSec driver.
|
10. | Computer Blue’s IPSec driver uses the inbound SA to retrieve the keys and processes the packets if necessary.
|
11. | The
IPSec driver converts the packets back to normal IP packet format and
passes them to the TCP/IP driver that passes them to the receiving
application.
|
12. | IPSec
SAs continue processing packets. SAs are refreshed by IKE Quick Mode
negotiation for as long as the application sends and receives data. When
the SAs become idle, they are deleted.
|
13. | IKE
Main Mode is not deleted when idle. It has a lifetime of 8 hours, but
this number is configurable (5 minutes to a maximum of 48 hours). New
traffic triggers a new Quick Mode negotiation. If IKE Main Mode expires,
a new IKE mode is negotiated when needed.
|
Note
Switches
and routers between Computer Red and Computer Blue will simply forward
the encrypted packets to their destination. However, a firewall or
packet filtering router must be configured to allow IPSec traffic to
pass. |
Creating an IPSec Policy
Creating an IPSec Policy
is easy. Creating one that does exactly what you want it to is not
always so easy. This far, you have learned how policy works. Now you
will use that knowledge to create a simple policy that you can use to
block access to port 80 and another to ensure encryption of data between
two computers. The two major tools used to create policy are IP
Security and Netsh. The next section describes how to create a policy
from the command line. The exercises at the end of this section teach
you how to use the GUI tool and Netsh.
Using Netsh to Manage IPSec
Netsh
is a native Windows Server 2003 command-line scripting tool that you
can use to display or modify the local or remote network configuration
of a computer running Windows Server 2003. You can run Netsh from a
batch file or from the command prompt. The Netsh IPSec commands cannot
be used on any other Windows computer.
See Also
You
can find a complete list of Netsh IPSec commands in the Windows Server
2003 Help And Support Center. You can locate them by clicking Tools,
then Command Line Reference. Note that many of the commands look
complex, but they can be simplified. If you use the same choices as the
command uses for its defaults, the commands you must type in can be
reduced. For example, you don’t need to use the word “Kerberos” if that
is the form of authentication you want to use. Enter nothing, and the
command defaults to using Kerberos authentication. |
To set the Netsh IPSec context, type the word static or dynamic
while in the Netsh IPSec context. Our discussion is concerned only with
Netsh commands that are useful to establish and monitor IPSec.
Once you have a
context, you can use the Netsh commands to produce a policy or monitor
IPSec activity. Two modes are possible. Static mode allows you to
create, modify, and assign policies without affecting the active IPSec
policy. Dynamic mode allows you to display the active state and
immediately implement changes to the active IPSec policy. Dynamic Netsh
commands affect the service only when it is running. If it is stopped,
dynamic policy settings are discarded.
Caution
Dynamic
mode can be quite useful, for example, if you need to immediately
initiate a change to IPSec processing. Although some IPSec commands
require you to stop and start the IPSec service, others do not. However,
Dynamic mode can also be a mixed blessing. Should you make a mistake in
Dynamic mode, you will have no opportunity to discover it before
implementing the change. You could end up creating an incorrect
configuration without warning. |
Using Netsh to Monitor IPSec
You can use Netsh to monitor the current IPSec session. Monitoring
consists of either displaying policy information, getting diagnostics
and logging IPSec information, or both. Any information you can find by
running the IP Security Monitor snap-in, you can find by running Netsh.
Displaying IPSec Policy Information
First, of course, you might want to know what the current IPSec Policy
is. To find out, you can use the Show command. If you choose to use the
Show All command, a lot of information will be returned.
Netsh ipsec static show all
Sometimes it is useful to
look at only a portion of the IPSec configuration information. A wide
range of Show commands is available. Some are defined in Table 1.
You can enter all commands from the Netsh IPSec Dynamic or the Netsh
IPSec Static context, or, with modification, from the command line.
Table 1. Netsh IPSec (Dynamic|Static) Show Commands
Operation | Command |
---|
Displays a specific filter list | Show Filterlist Name=filterlistname
|
Displays the policy assigned to the specified GPO | Show Gpoassignedpolicy Name=name
|
Displays a specific policy | Show Policy Name=policyname
|
Displays a specific rule | Show Rule Name=rulename
|
Obtaining Diagnostic IPSec Information One
of the steps in diagnosing IPSec problems—or just establishing that the
policy is working like you think it should—is to obtain information
about the current policy. The Show commands described later in Table 2
provide that information. The information that each command reveals
identifies the settings in the policy. For example, the Show Filterlist
command lists the information in the policies filter list. Filter list
options were listed in Table 11-6.
Table 2. IPSec Main Mode Statistics
Statistic | Description |
---|
Active Acquire | Number of pending requests for IKE negotiation for SA between IPSec peers. |
Active Receive | Number of IKE messages queued for processing. |
Acquire Failures | Number of failed outbound requests to establish SA since IPSec service started. |
Receive Failures | Number of errors in receipt of IKE messages since IPSec service started. |
Send Failures | Number of errors during sending of IKE. |
Acquire Heap Size | Number of successive outbound requests to establish SAs. |
Receive Heap Size | Number of IKE messages in IKE receive buffers. |
Authentication Failures | Number
of failed authentication failures since the IPSec service started. If
you cannot make an IPSec connection, check to see whether authentication
failures increase during an attempt. If so, authentication is the
issue. Check to see that shared secrets match, peers are members of the
domain, and certificates are correct. |
Negotiation Failures | Number
of Main Mode negotiation failures. Attempt to communicate and see
whether negotiation failures increase. If so, check authentication and
security method settings for unmatched or incorrect configuration. |
Invalid Cookies Received | Number of invalid cookies. A cookie is a value in an IKE message that is used to help identify the corresponding Main Mode SA. |
Total Acquire | Number of requests submitted to IKE (including those resulting in soft SAs). |
Total Get SPI | Number of requests to driver for SPI. |
Key Additions | Number of outbound Quick Mode SA additions. |
Key Updates | Number of inbound Quick Mode SAs added by IKE. |
Get SPI Failures | Number of failed requests for a unique SPI. |
Key Addition Failures | Number of failed outbound Quick Mode SA addition requests submitted by IKE. |
Key Update Failures | Number of failed inbound Quick Mode SA addition requests. |
ISADB List Size | Number
of Main Mode state entries, successful Main Modes, Main Modes in
negotiation, and those that fail or have expired but have not been
deleted. |
Connection List Size | Number of Quick Mode negotiations in process. |
IKE Main Mode | Number of successful SAs in Main Mode. |
IKE Quick Mode | Number of successful SAs that have been created during Quick Mode negotiations since the IPSec service was last started. |
Soft Associations | Number
of SAs formed with computers that have not responded to Main Mode
negotiation attempts since the IPSec service was last started. Although
these computers did not respond to Main Mode negotiation attempts, IPSec
policy allowed communications with the computers. Soft SAs are not
secured by IPSec. |
Invalid Packets Received | Number
of invalid IKE messages. Invalid header fields, payload lengths, and
incorrect values. Check to see whether the preshared key is matched in
the peer configuration. Invalid Packets Received statistics might also
be the result of retransmitted IKE messages. |
Some examples of the
Show command syntax are illustrated next. In the commands, the equal
sign is part of the command and the italicized words are replaced by
some value as indicated below the command.
Show All Resolvedns=value
Resolves the DNS or NetBIOS computer name associated with an IP
address. This command might assist you in determining whether the policy
is affecting the right computer.
Show Mmsas
Displays information on the IPSec Main Mode SA. You can see the source
and destination addresses. When used with the Resolvedns=yes switch, the
names of the computers are also displayed.
Show Qmsas Displays information about the IPSec Quick Mode SAs.
Show Stats Displays the IKE Main Mode statistics, IPSec Quick Mode statistics, or both.
In addition to
Show commands, you can use several Dynamic mode Netsh IPSec diagnostic
commands to obtain diagnostic information, such as the following:
Set Config Property=Ipsecdiagnostics value=value
Can be set with a value of 0 through 7, indicating the level of IPSec
diagnostic logging. The default is 0, which means logging is disabled.
The level 7 causes all logging to be performed. The computer must be
restarted for logging to begin.
Set Config Property=Ipsecloginterval value=value
Indicates how frequently in seconds the IPSec events are sent to the
system event log. The range is 60 to 86,400 with a default of 3600.
Set Config Property=Ikelogging value=value Can
be set with a value of 0 or 1, determining whether IKE (Oakley) logging
will occur. This command produces a log with a copious amount of
information. You must be familiar with the RFCs at the expert level to
completely understand the Oakley logs.
Set Config Property=Strongcrlcheck value=value
Determines whether certificate revocation list (CRL) checking is used.
If 0, CRL checking is disabled. If 1 is the value, certificate
validation fails only if the certificate is revoked. Level 2 fails if
any CRL check error occurs. A CRL check fails if the CRL cannot be
located on the network.
You can make other
diagnostic efforts by modifying the current policy to reduce security.
For example, if you change authentication to Shared Secret on both
computers instead of Kerberos or Certificates, you eliminate the
possibility that the problem is related to authentication. Netdiag.exe
is a command-line tool that you can use to display IPSec information as
well as to test and view network configuration. Netdiag is available
for Windows Server 2003, Windows 2000, and Windows XP. However, it must
be installed in a different way for each operating system. For Windows
Server 2003, Netdiag is installed with the Windows Server 2003 Support
Tools. For Windows 2000, Netdiag is included with the Windows 2000
Resource Kit tools that you can also download from the Internet. It is
also available on the Windows XP Installation CD-ROM, and is installed
by running Setup.exe from the Support\Tools folder.
You can obtain
general network diagnostic information (not IPSec-specific) by using the
Netdiag command. For example, the Netdiag /v /l command provides the IP
configuration and routing configuration for a computer, tests WINS and
DSN name resolution, reports the build version of the computer and the
hotfixes that are installed, tests the validity of domain membership,
verifies contacts by member computers with their domain controllers, and
checks trust relationships. All of this information can be useful in
eliminating general networking problems before attempting to diagnose
IPSec issues.
However, although
the Netdiag.exe tool is available for Windows Server 2003, the Netdiag
/test:ipsec option is removed. Use the Netsh command instead. Because
Netsh IPSec context commands will not work with downlevel Windows
computers, use Netdiag for them. You might want to remotely examine the
IPSec policy of a computer running Windows XP or Windows 2000 that is
communicating, or attempting to communicate, with Windows Server 2003.
In this case, use a remote desktop session and the Netdiag tool.
Using IP Security Monitor to Monitor IPSec Traffic
IP Security Monitor
is a Windows XP and Windows Server 2003 snap-in used to monitor and
troubleshoot IPSec. If an IPSec policy is active, you can use this
console to examine the policy and its operations. You can use the IP
Security Monitor console to monitor computers of only the same version
as the one running the monitor. Information that you can obtain includes
the following:
Name of the active IPSec policy
Details about the active IPSec policy
Quick Mode statistics
Main Mode statistics
Information about active SAs
Note
IPSec
monitoring tools exist for Windows 2000 as well. To monitor IPSec on
computers running Windows 2000, use the Netdiag Support Tool, the
Ipsecmon.exe utility, or both. |
Understanding Main Mode and Quick Mode Statistics in IP Security Monitor
Viewing IPSec statistics is simply a matter of expanding the server
node, expanding the Main Mode node or the Quick Mode node, and then
selecting the Statistics node. Understanding what each statistic means
is more difficult. Table 2 describes the most common Main Mode statistics, and Table describes the most common Quick Mode statistics. Within Table 2,
several statistics appear to be related to Quick Mode. They are, but
they are initialized by IKE during Main Mode, hence their inclusion as
part of the Main Mode statistics table.
Table 3. IPSec Quick Mode Statistics
Statistic | Description |
---|
Active Security Association | Number of Quick Mode SAs. |
Offloaded Security Associations | Number of Quick Mode SAs offloaded to hardware. |
Pending Key Operations | Number of key exchange operations in progress. |
Key Additions | Number of keys for Quick Mode SAs successfully added since computer started. |
Key Deletions | Number of keys for Quick Mode SAs successfully deleted since computer started. |
Rekeys | Number of successful rekey operations for Quick Mode. |
Active Tunnels | Number of active tunnels. |
Bad SPI Packets | Number
of packets with incorrect SPI. Possibly the SPI has expired and an old
packet just arrived. Likely to be larger if rekeying is frequent and
there are a large number of SAs. Might indicate a spoofing attack. |
Packets Not Decrypted | Number
of packets that could not be decrypted since the computer was last
started. A packet might not be decrypted if it fails a validation check. |
Packets Not Authenticated | Number
of packets for which data could not be verified (for which the
integrity hash verification failed) since the computer was last started.
Increases in this number might indicate an IPSec packet spoofing or
modification attack or packet corruption by network devices. |
Packets With Replay Detection | Number of packets containing an invalid sequence number. Increases might mean network problems or a replay attack. |
Confidential Bytes Sent | Number of bytes sent using the ESP protocol. |
Confidential Bytes Received | Number of bytes received using the ESP protocol (excluding nonencrypted ESP) since the computer was last started. |
Authenticated Bytes Sent | Number
of authenticated bytes sent using the Authentication Header (AH)
protocol or the ESP protocol since the computer was last started. |
Authenticated Bytes Received | Number of authenticated bytes received using the AH protocol or the ESP protocol since the computer was last started. |
Transport Bytes Sent | Number of bytes sent using IPSec Transport mode. |
Transport Bytes Received | Number of bytes received using IPSec Transport mode since the computer was last started. |
Bytes Sent In Tunnels | Number of bytes sent using IPSec Tunnel mode. |
Bytes Received In Tunnels | Number of bytes received using IPSec Tunnel mode. |
Offloaded Bytes Sent | Number of bytes sent using hardware offload. |
Offloaded Bytes Received | Number of bytes received using hardware offload. |
Using Netcap to Capture Network Traffic
Netcap.exe
is a command-line utility that you can use to capture network traffic
to a capture file. You can then load the file in Network Monitor to view
the captured traffic. The Network Monitor tool does not have to be
installed on the computer running Windows Server 2003 to use Netcap. You
can also use Netcap on computers running Windows XP, which makes it an
extremely attractive way to capture traffic for later review. The tool
is available after the Windows Server 2003 Support Tools have been
installed. When you first run the command, the Network Monitor driver is
automatically installed.
Table 4 describes the syntax used to obtain a capture.
Table 4. Netcap Syntax
Options | Description |
---|
/b:Number | Specifies buffer or capture size from 1 MB to 1000 MB with a default of 1 MB. |
/t Type Buffer HexOffset HexPattern | Informs
trigger when to stop the capture, when either the buffer or pattern is
reached. The capture stops when the buffer is full if no trigger is
defined. /t N can be used to cause the capture to continue when the
buffer is full. New frames overwrite the oldest frames.
Valid values for the Type
parameter are B = buffer; P = pattern; BP = buffer then pattern; PB =
pattern then buffer; N = no trigger.
Valid values for the Buffer parameter are % Buffer size 25, 50, 75, and 100. This parameter is used with all Type values except P.
Valid values for the HexOffset parameter are hex offset from
start of frame used with P, BP, PB, but not B. Valid values for the
HexPattern parameter are hex pattern to match. Used with P, BP, PB, but
not B. The pattern needs to be an even number of digits. |
/C:CaptureFile | Specifies
a location where Netcap will move the temporary capture files. This
location can be any valid local or remote path. If /C is not specified,
the capture path remains in the default temporary capture folder. |
/F:FilterFile.cf | Specifies a filter to use during the capture. A filter file has a .cf extension. |
/L:HH:MM:SS | Captures for some amount of time. |
/TCF:FolderName | Changes temporary capture folder. Path must be on a fixed local hard disk drive. |
/Remove | Removes Netcap instance of the Network Monitor driver. |
/N:Number | Provides
the NIC index number for this computer. 0 = PPP/SLIP interface. 1 =
Local Area Connection 2; 2 = Local Area Connection. Determine the NIC
index number using the Netcap /? command. All adapters installed on the
local computer will be listed. |
The following are two example commands:
Capture the packets received on NIC 2 using a 20-MB buffer:
Capture for one hour: