[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: problems with draft-jenkins-ipsec-rekeying-06.txt
Of course this is way late, but it would have been nice if the draft had
given some discussion on the alternative loss-less rekey implementation
method suggested in RFC 2408 (the NOTE: in section 3.1).
The implementation note is extremely sketchy and it would have been nice if
this draft could have provided some additional details on this method. This
is how I interpreted the suggestion:
Incoming IPsec packets with unrecognized SPIs are treated in a similar
fashion to packet fragment collection (e.g., queued up with a time limit and
memory consumption limit - the time limit is much smaller than one would use
in fragment collection). The IKE daemon is informed of the reception of the
unknown SPI (with less frequency than some specified minimum so as not to
flood the daemon). If the SPI/protocol/addresses match that of a phase 2
exchange that's waiting for a third QM (or notify connected) message then
the system "sets up" the SA (inbound and outbound) as if it had received the
message it was waiting for and the queued unrecognized SPI packets are then
processed. Otherwise it's a bogus SPI and the packets are thrown away and
the event logged (if an IKE SA exists with the source of the packet a delete
notify can optionally be sent).
This method doesn't require pre-setup or a splitting of the inbound and
outbound SAs and seems to handle the dropped 3rd QM, dropped connected
notify, and out-of-order QM3/IPsec problems nicely. This method also helps
for the case where a delete notify was dropped (if the peer continues to use
that SPI it will get another delete notify).
-dave