Mailing List Archive

What is necessary for an implementation of rekeying?
Hi!

As I would really be interested in the rekeying feature, I just wondered
if I could try to implement it or at least prototype. Hence, I would
like to get a starting point where to look for the specification of the
rekeying. In the RFCs on the vpnc website, I did not find an exact
specification of how rekeying is initiated and performed. Could anyone
give me a pointer where to start?

Best regards,
Marco
What is necessary for an implementation of rekeying? [ In reply to ]
hi,

> As I would really be interested in the rekeying feature, I just wondered
> if I could try to implement it or at least prototype. Hence, I would
> like to get a starting point where to look for the specification of the
> rekeying. In the RFCs on the vpnc website, I did not find an exact
> specification of how rekeying is initiated and performed. Could anyone
> give me a pointer where to start?

if I've read the rfcs correclty (ISAKMP iirc), both peers can decide
to negotiate a new SA any time. After the new SA is established, the
old one is deleted. The SA will be deleted too if the liftime limit
(data, time, both) is exceeded.

vpnc does NOT currently do any accounting about when a SA is about
to expire. Neither is the poll()-loop listing on the isakmp socket
at all.

currently I am planning a new structure for vpnc which would allow
better integrating of handling rekeying and NAT-T. I'm thinking
about using a central loop which then either calls isakmp or ipsec
code. The current model is doing isakmp exchandes first, and
always expect that a isakmp-packet received is an answer to the last
send paket. Currently it is not really possible to receive to
consecutive packets from the concentrator without sending one...
(this is the reason why vpnc moans about INVALID_EXCHANGE_TYPE
instead of displaying the error-notice which the concentrator
has sent)

cu
maurice