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.

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.

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.

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.

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 (https://support.microsoft.com/default.aspx?scid=kb;en-us;233256)

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

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

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.

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” - https://www.osronline.com/ddkx/network/209offl_4tev.htm

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

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.