kload that it then has to churn), in tunnel mode. How the link performance is degraded when the link is sustained as simplex or as full duplex. What happens under a specific and pertinent key exchange protocol. The exact context of the exchange environment must be defined, SO that oranges are compared with oranges, SO to speak. For instance, one may want to know what happens when IKE is used with a DH operation, an RSA (or DSA) signature generation, and an RSA (or DSA) signature verification where the key sizes are standardized. For example, some DH cases can use 180-bit exponents and RSA keys can be stipu- lated to be 1,024 bits (typically good security) or 2,048 bits (much more conservative security) and SO forth. Do not neglect finding out how the IPsec accelerator behaves in a more subtle situation where it must be decided whether the consecutively flowing packets belong to different SAs. Many vendors would assume that many of the consecutive packets belong to the same SA and therefore the configu- ration data are readily available in a lookup table. This is one extreme case that suits the vendor. A ques- tion at the other extreme of the argument should be asked instead-namely, how is the performance affected if all parading packets during the test belong to different security associations and the crypto- graphic context has to be completely updated after each packet has been processed? The truth of a typ- ical case would then lie somewhere in the middle. With this fundamental set of overall IPsec performance parameters more or less delineated, the potential user should then go even deeper into the relevant worth of actual hardware-assist units and probe deeper into the vendor claims in order to ultimately bring out the real substance of performance numbers, which are relevant to one's own design requirements and targets. The public-key-related questions that must be answered by a prospective vendor are listed in the section "SSL Acceleration." On the cipher side, the prospective user must also keep an eye on