[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ESP revisions straw poll
Stephen,
It took awhile for me to remember the history of this. Having worked on an earlier protocol that may have influenced some of this work, there may be some motivation to keep the IV in a separate exchange. In our case, it was necessary to keep the IV in a separate exchange for reasons other than cryptographic algorithm or mode. We elected to send the IV in a separate exchange to accommodate encryption of applications which are more time sensitive than dependent on reliable transport -- real-time interactive stuff. In any case, it is desirable to ensure the IV is transferred without errors, but it is often tolerable to have bit errors in the traffic (voice and video services for example). Therefore, it was desirable to use a difference service for transmission of the IV in comparison to the traffic. This information may have little bearing on this work, but it was certainly relevant in our implementation.
Brian Rexroad
AT&T Information Security Center
brexroad@att.com
-----Original Message-----
From: Stephen Kent [SMTP:kent@bbn.com]
Sent: Tuesday, May 13, 1997 9:06 PM
To: ipsec@tis.com
Subject: ESP revisions straw poll
Folks,
In an effort to reach closure on the suggested changes to the latest ESP
spec, I suggest the following revision, in addition to my earlier message
about authenticationless ESP:
- The optional IV field will be removed; if an encryption algorithm
requires an IV, it will be transmitted as the initial portion of the
ciphertext payload. The definition of the encryption algorithm as provided
for use with ESP, will specify the presence (or absence) or an IV, and
describe its length. the recent I-Ds on RC5 and CAST adopt this approach
to algorithm definition.