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