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

Alternative transform encapsulation scheme

Now that we're heading toward individual do-everything transforms
rather than layered orthogonal functions, the concept of separate AH
and ESP protocols seems a bit awkward.  Consider a different protocol,
perhaps called `Security Transform', that might look like this:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Security Parameters Index (SPI)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Transform ID          |    Length     |  Next Header  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Optional Transform Data                    ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Transforms could be layered if desired.  The length field would make
it easy to parse even if you didn't understand a particular transform
type.  All of our code would become simpler, and the RSVP folks would
love this more uniform format.

The Next Header field would be slightly problematic; encrypting
transforms would want to obscure it somehow (perhaps destroying it
after storing a copy down in the opaque area) while not obscuring
portions of the Optional Transform Data field such as initialization
vectors.

I know it's pretty late in the game to begin talking about something
like this, but it only recently became appropriate because of the
recent change in attitudes toward combined transforms.
--
Karl Fox, servant of God, employee of Morning Star Technologies
3518 Riverside Drive, Suite 101, Columbus, Ohio 43221    +1 614 451 1883
Follow-Ups: