>>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
Mark,