Re: [RPSEC] rate limiting management traffic, redux

[Mark Handley <mjh@icir.org>]

>>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?

>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'm not sure I understand your solution, so let me see if I can
restate it.

Suppose I have two routers, A and B that were communicating securely.
Now, A restarts.  How is B going to accept any more packets from A, as
A can no longer send packets that fall in the window?

I think you implied (trying to fill in the details myself): 

 - A sends a re-initialization packet to B with nonce_A. 

 - B replies with nonce_A and a new nonce_B. 

 - A sends nonce_A and nonce_B back to B along with the new sequence
   number it wants to use and the one-way hash of nonce_A, nonce_B,
   the new sequence number and the secret.

 - On success, B sends nonce_A and nonce_B back to A, the new sequence number
   specified by A, and the one-way hash of nonce_B (but not nonce_A to
   avoid replay) the new sequence number and the secret.

On success, the new secret becomes the hash of the old secret and the
two nonces.

The reason for the last phase is to avoid a DoS vulnerability from
someone who can see traffic from A to B.  They can flood A with
re-initialization replies giving many different values of nonce_B.
Router A will have to respond to all of them to reliably set up
communication.  So we need to add a final phase so A unambiguously
knows which one was successful.  Also need to be careful not to be
used as an oracle - I think the above is OK, but I may have missed
something.

Is this more or less what you had in mind?

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