Re: [RPSEC] rate limiting management traffic, redux

[Stephen Kent <kent@bbn.com>]

At 1:57 PM -0700 4/17/03, Mark Handley wrote:
>  >There are a few open issues:
> > 	- where to carry the sequence number and tag
> > 	- how big is the sequence number and how big is the tag
> > 	- how big is the key
> > 	- what one-way function to use
> >
> > Comments?
> What do you do about sequence number re-initialization?  If this is
> being used to protect routing traffic, and a router restarts, do you
> require stable storage to preserve the previous sequence numbers?
>
>  - Mark
Mark,

Good question.

At a minimum, stable storage is needed for the keys, but they change 
slowly, so maintaining that ought not be too hard. It would be harder 
for the per-sender window data to be saved, so we ought to have a 
plan for re-initialization.

A likely approach is to have the router that crashed initiate a 
connection to each authorized management entity to reinitialize, 
e.g., putting a new key in place and resetting the sequence number to 
zero. In the re-initialization process, the router would engage in a 
handshake with the management entities, using a nonce to ensure 
freshness, and because the router initiated the handshake, it can at 
least be protected against an attacker without access to the packets 
it sends as part of the re-initialization process. We may be able to 
be clever here too. For example, we could take the nonce generated by 
the router and use it as an input to generate the new key from the 
old key, so that the router and the management entity can very 
quickly transition to the new key and resume secure communication. 
I'll have to work out the details, but I think it's feasible with a 
quick UDP exchange.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec