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

Re: Security Association Lifetimes in kbytes



> In order to get consistency in implementations of various
> IP Security products, I wanted to ask about implementing
> lifetimes in terms of kbytes.

How about bytes?  (You'll notice PF_KEYv2 uses a uint64_t to count the number
of _bytes_ an SA consumes.)

> Is it assumed that we use the length field in the IP header?
> If so, won't the effect vary depending on IP V4/ IP V6 and
> various options that are selected that determine the number
> and size of headers and MTU sizes?  How would an administrator
> know how much to increment the size to account for this type
> of overhead?

IMHO, and in my code, I count "number of bytes used by the primary
algorithm".  For ESP, this means the number of bytes I encrypt/decrypt.  For
AH, this means the number of bytes I feed into the authentication algorithm.

> How do we handle overlap to refresh the keys before the
> previous SA expires?

You'll notice also in PF_KEY that there are two kinds of lifetimes, a _SOFT_
lifetime, and a _HARD_ lifetime.  When the soft lifetime expires, an
SADB_EXPIRE message goes up.  A KMd can consider this a warning to perhaps go
negotiate a replacement SA.

I dunno if you're using PF_KEY in your implementation, but if you are, it has
all of the facilities... you just need to implement the abstraction of soft
and hard lifetimes in your SADB.

> Is this usually a user-configurable option of some percentage of the
> lifetime? Seems success at refreshing the keys would vary depending on
> whether the data is bursty or not.

See above for one solution.

> Can the tunnel expire in the middle of a packet, or do we
> implement it on packet boundaries? Do you toss the packet
> if the entire packet does not make it in the lifetime?

I do toss the packet if the entire packet does not make it in a lifetime.

> Would appreciate your feedback.

Hope this helps!
--
Daniel L. McDonald  -  Solaris Internet Engineering  ||  MY OPINIONS ARE NOT
Mail: danmcd@eng.sun.com, danmcd@kebe.com <*>        ||  NOT NECESSARILY SUN'S!
Phone: (650) 786-6815            |"rising falling at force ten
WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush


References: