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

Re: (IPng) Re: out-of-band key management is like virtual circuits




Ashar Aziz says:
> Now, with SKIP I can establish and change keys, even if your
> node is down. With other session oriented key-mgmt schemes
> this cannot be done.

One wonders of the utility of establishing a key for use with a host
that isn't up.

> It is in this sense that SKIP is stateless

SKIP is emphatically NOT stateless -- at least not if it performs
remotely well. As I've noted, unless you are going to do a key lookup
in a key database for every packet that comes in, you are going to
have to cache just as much state as everyone else.

> SKIP cached information is good across reboots. 
> 
> The information that some of the other key-mgmt protocols maintain 
> (e.g. session keys) is not good across reboots.

Why wouldn't it be? You say that if you have NVRAM you can do this
miraculous preservation of SKIP cached information across reboots, but
as I've noted, if you actually had nonvolitile ram to cache security
association information in across reboots, there would be no reason
any other key management protocol couldn't maintain state,
too. Furthermore, reboots are an extremely unusual circumstance, and I
don't think that maintaining associations across reboots is going to
impact reboot times as much as, say, file system consistancy
checks. (By the way, my routers typically are rebooted on the order of
once a year or less.)

> > > Yes, but we are not talking about a security protocol just for TCP.
> > 
> > Thats completely irrelevant. You just put an inactivity timer on your
> > SA structures and they clean themselves up. Bit deal.
> > 
> > ShowMe is a very heavyweight application -- you get data packets from
> > it on a constant basis. I would expect, then, that the half-open state
> > problem would not be a problem -- a two minute inactivity timer on
> > your state would easily handle the problem. 

> No, it wouldn't. ShowMe will send video regardless of whether
> the remote node is up or down. There will be no inactivity, and so 
> the inactivity timer will never go off. 

The inactivity timer is at the RECEIVER, not at the SOURCE. Security
associations are different in each direction.

.pm


References: