Freigeben über

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

  • Artikel

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

Comments