[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
-------------------------------------------------------------------------------