Separate SA for each TCP connection

[Ernest Dainow <Ernest.Dainow@mcdata.com>]

I think that the requirement that every TCP connection must have its own SA
(Security Association) has a number of problems. 

First of all, it is difficult to enforce on the receiving side, if the
sending end does not comply with this requirement and uses an existing SA
for a second TCP connection. When IPSec receives a packet with a valid SPI,
it cannot discover that the packet was sent on a different port number than
the SA was set up for until after the security processing. 

To meet this requirement, extra checking must be done to compare every
packet to the SPD (Security Policy Database) after security processing. If
this is done, then various interoperability problems may occur when
communicating with an end device that is using standard IPSec.

The SPD is configured with Source IP:Port, Destination IP:Port. When an
administrator configures this, the source port is not known and so a wild
card is usually used. In standard IPSec implementations, this means that
multiple connections to the same destination address:port will travel down
the same SA.

Interoperability between standard IPSec and IPS IPSec may be needed in a
number of situations:
1. Using tunnel mode to connect to a storage device behind a gateway, such
as a firewall (which terminates the IPSec connection).
2. Connections to an iSNS or SLP server which likely will be implemented on
an industry standard OS that uses standard IPSec. 
3. If the IP/IPSec stack on the IPS device is used as a TCP offload engine
for traffic other than storage. Common uses might be for management such as
telnet.

The only reason for this requirement that I could find is in Section 5.8.3
of draft-ietf-ips-security-09.txt. 

"IPsec implementations that only support machine authentication typically
have no way to distinguish between user traffic within the kernel. As a
result, where machine authentication is used, once an Ipsec SA is opened,
another user on a multi-user machine may be able to send traffic down the
IPsec SA. To limit the potential vulnerability, iSCSI, iFCP or FCIP security
implementations MUST negotiate a separate IPsec Phase 2 SA for each
connection, with descriptors specific to that connection."

This is a general feature/limitation of IPSec. IPSec by definition operates
at the network layer. If application layer authentication is desired, it
should be done by the application. iSCSI has the option to use SRP or other
authentication methods. Proposals have been made for FCIP to provide an
option for user authentication based on SRP, consistent with iSCSI, but
current direction has been to favor a Fibre Channel based authentication
scheme (yet to be defined).

The potential interoperability problems resulting from the requirement to
have a separate SA for each TCP connection is not worth the attempt to
"limit" this vulnerability, when other clean ways exist to establish user
authentication.

Ernie Dainow