[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Separate SA for each TCP connection

    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
    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
    Ernie Dainow


Last updated: Mon Feb 18 12:18:07 2002
8782 messages in chronological order