[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Status of IPSEC Key Management
> > > One way to do this would be to include fields saying "respond to this
> > > on SPI <NNN> until <expiration>" in the in-band-keying header; once an
> > > explicit SPI had been set up between peers, the in-band header would
> > > not be used.
>
> So would a message be sent back acknowleging this key change?
Use of the reply-SPI by the peer would (implicitly) acknowledge the
key change.
> What would you do if the key change packet was dropped?
Keep sending in-band keying messages (with the same reply SPI) until
the peer shows evidence of having "gotten it".
This would just be piggybacked on the retransmissions (if any) of the
upper-level protocol.
When sending a packet, if there isn't a valid outbound SPI we want to
use to reach the peer, we look up the inbound SPI we want our peer to
use (or create it if it's nonexistant) and insert an in-band keying
header in the outbound packet.
On the other hand, if there is a valid outbound SPI, we use it. If
there isn't a valid inbound SPI for a response, we create the inbound
SPI we want to receive replies on and insert an in-band-keying header
in the outbound packet, then send it to the outbound SPI.
If an inbound packet contains a valid in-band-keying header with a
reply SPI in it, we create the outbound SPI with the appropriate TTL.
- Bill