5.3. Clock Synchronization (original) (raw)

Connected: An Internet Encyclopedia
5.3. Clock Synchronization

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1446
Up: 5. Clock and Secret Distribution

Prev: 5.2. Clock Distribution
Next: 5.4. Secret Distribution

5.3. Clock Synchronization

Unless the secrets are changed at the same time, the correct way to synchronize clocks is to advance the slower clock to be equal to the faster clock. Suppose that party agentParty is realized by the SNMPv2 entity in a managed agent; suppose that party mgrParty is realized by the SNMPv2 entity in the corresponding responsible management station. For any pair of parties, there are four possible conditions of the authentication clocks that could require correction:

The management station's notion of the value of the authentication clock for agentParty exceeds the agent's notion.
The management station's notion of the value of the authentication clock for mgrParty exceeds the agent's notion.
The agent's notion of the value of the authentication clock for agentParty exceeds the management station's notion.
The agent's notion of the value of the authentication clock for mgrParty exceeds the management station's notion.

The selective clock acceleration mechanism intrinsic to the protocol corrects conditions 1, 2 and 3 as part of the normal processing of an authentic message. Therefore, the clock adjustment procedure below does not provide for any adjustments in those cases. Rather, the following sequence of steps specifies how the clocks may be synchronized when condition 4 is manifest.

The responsible management station saves its existing notion of the authentication clock for the party mgrParty.
The responsible management station retrieves the authentication clock value for mgrParty from the agent. This retrieval must be an unauthenticated request, since the management station does not know if the clocks are synchronized. If the request fails, the clocks cannot be synchronized, and the clock adjustment procedure is aborted without further processing.
If the notion of the authentication clock for mgrParty just retrieved from the agent exceeds the management station's notion, then condition 4 is manifest, and the responsible management station advances its notion of the authentication clock for mgrParty to match the agent's notion.
The responsible management station retrieves the authentication clock value for mgrParty from the agent. This retrieval must be an authenticated request, in order that the management station may verify that the clock value is properly synchronized. If this authenticated query fails, then the management station restores its previously saved notion of the clock value, and the clock adjustment procedure is aborted without further processing. Otherwise, clock synchronization has been successfully realized.

Administrative advancement of a clock as described above does not introduce any new vulnerabilities, since the value of the clock is intended to increase with the passage of time. A potential operational problem is the rejection of authentic management operations that were authenticated using a previous value of the relevant party clock. This possibility may be avoided if a management station suppresses generation of management traffic between relevant parties while this clock adjustment procedure is in progress.

Next: 5.4. Secret Distribution

Connected: An Internet Encyclopedia
5.3. Clock Synchronization