Dear Robert, > Nit: (This was part of my early review of -00) > The claim in 1.1 about not requiring persistent storage is contradicted by the > definition of the protocol. At the very least, there is the need to persist the > most recent (index,PC) seen. I most respectfully disagree. The whole point of the challenge/response mechanism is to avoid the need for persistent storage. If a node loses the information about a neighbour (e.g. because it has rebooted and lost the index/PC of the neighbour), it can simply send a new challenge to recover the state. Here is what is written in Section 2 (Conceptual overview): By itself, the PC mechanism is not sufficient to protect against replay. Consider a peer A that has no information about a peer B (e.g., because it has recently rebooted). Suppose that A receives a packet ostensibly from B carrying a given PC; since A has no information about B, it has no way to determine whether the packet is freshly generated or a replay of a previously sent packet. In this situation, A discards the packet and challenges B to prove that it knows the HMAC key. It sends a "challenge request", a TLV containing a unique nonce, a value that has never been used before and will never be used again. B replies to the challenge request with a "challenge reply", a TLV containing a copy of the nonce chosen by A, in a packet protected by HMAC and containing the new value of B's PC. Since the nonce has never been used before, B's reply proves B's knowledge of the HMAC key and the freshness of the PC. Should you disagree with the fact that this mechanism allows a node to recover the state that it has discarded, I request that you provide an example scenario in which this mechanism fails. -- Juliusz
