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

Re: key life attributes (Was: Re: FW: tunnel mode)

Roy Pereira <rpereira@timestep.com> writes:
> Then we could have ESP transforms [...] with attributes of:
[...]
>         key life type (int) [default=0, no limit]
>                 seconds = 1
>                 kilobytes = 2
>         key life duration (int)

Is there interest in supporting a second-order key life, e.g. the
minimum of a "clock lifetime" (measured in secs) and a "bandwidth
lifetime" (measured in kb) ?  Then it's possible to express the
policy "it's time to change keys if the current key _either_ is old 
_or_ has been heavily used".

I imagine this would require adding a fourth key life type 
(i.e. 3) for the combo option, and a second (optional?) key life 
duration field for the second duration value. It might also be done
with implicit typing of the key lifetime(s) and reinterpreting the 
existing fields. The logic for the latter might look like:

if (KeyLifeDurVal[0] == 0)
   if (KeyLifeDurVal[1] == 0)
      /* unlimited lifetime */
   else
      /* bandwidth lifetime of KeyLifeDurVal[1] kb only */
   fi
else
   if (KeyLifeDurVal[1] == 0)
      /* time lifetime of KeyLifeDurVal[0] seconds only */
   else
      /* lifetime = MIN(KeyLifeDurVal[0] secs., KeyLifeDurVal[1] kb) */
   fi
fi

But my sense is that implicit typing is _not_ the way to go.

-Lewis	<http://www.cs.umass.edu/~lmccarth>
References: