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

Hardware support



An issue that wasn't addressed so far as related to the IPSP packet format is
provision for support by hardware for fast links. I believe it is important the
agreed on packet format does not preclude the use of an outboard `crypto
engine' to accelerate encryption. The hardware would be built in such a fashion
to perform cryptographic processing on packets as they traverse the link as
opposed to a DES chip that resides on the system bus. A typical configuration
would be to have the device attached between the host's Ethernet interface and
the backbone segment.

There are several requirements from the packet format that would simplify the
parsing performed by the device and enhance its performance. These are
prerequisites to the design of a low-cost device:

[1] The ICV (Integrity Check Value) should be placed at the end of the 
    packet as a trailer rather than as part of the header. This would allow 
    the device to calculate and check the ICV while packets flow through it
    (`cut through') without the need to use store and forward thus reducing
    latency.

[2] The integrity/authentication algorithm used should be the same
    as used for encryption to reduce hardware complexity. One way of
    achieving an ICV with DES/CBC is to use the DES residue. Using separate
    algorithms for encryption and authentication means implementing
    both algorithms in hardware; this could be complex and expensive in terms 
    of chip real estate.

[3] Use an 8-byte SAID (or Key ID) field. The hardware needs to determine from
    the contents of an incoming packet how decryption should be performed. A
    common approach is to use an index into a table containing encryption
    keys. A drawback of this approach is that it forces the device to 
    store a potentially large table of keys.

    A different approach is to use an encrypted DES key. The device
    performs 2 iterations of decryption: It first decrypts the key received
    in the packet with a ``Master key'' not known to anyone by itself. 
    Subsequently, the data is decrypted with the resulting key.
    Keys are established using Diffie-Hellman or a similar process. The
    hosts then each encrypt the session key under their master key and
    send the result to each other for subsequent inclusion in data packets.

[4] Include a fragmentation/reassembly mechanism to eliminate the need
    to perform fragmentation by IP on the originating system. A fragmented
    packet cannot be decrypted by hardware ``on the fly'' due to
    several reasons; A simple and inexpensive device cannot be expected to 
    maintain context between fragments to perform decryption. The best it can 
    do is detect that fragmentation has taken place and pass the packet 
    unmodified to the host which will handle decryption.

    Many popular implementations of NFS generate 8K UDP packets that
    are fragmented by IP on the originating system. Such packets cannot
    be cryptographically processed by hardware. Incorporating a
    fragmentation facility into IPSP would eliminate this problem as
    packets would be fragmented at this level rather than by IP, thus
    the IPSP header would be included in every packet.

Dan

-------------------------------------------------------------------------------
Dan Frommer               	   |
Digital Equipment Corporation	   |	Internet:  dan@isv.dec.com
P.O. Box 10109		  	   |	Phone   :  +972 2 782551
Jerusalem 93 469, Israel  	   |	Fax     :  +972 2 782373
-------------------------------------------------------------------------------