IS-IS Packet Timestamping
draft-many-lsr-isis-packet-timestamping-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Tony Przygienda , Colby Barth , Tony Li , Joel M. Halpern | ||
| Last updated | 2026-07-01 | ||
| Replaces | draft-rigatoni-lsr-isis-fragment-timestamping | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Yang Validation | 0 errors, 1 warnings | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-many-lsr-isis-packet-timestamping-00
Network Working Group T. Przygienda
Internet-Draft C. Barth
Intended status: Standards Track T. Li
Expires: 2 January 2027 J. Halpern
HPE Juniper Networking
1 July 2026
IS-IS Packet Timestamping
draft-many-lsr-isis-packet-timestamping-00
Abstract
Many applications in today’s networks rely on reliable and timely
flooding of link-state information, such as, but not limited to
Traffic Engineered networks. If such link-state information is
delayed it can be difficult for those applications to adequately
fulfill their intended functionality. This document describes
extensions to ISIS supporting distribution of fragment origination
time. The origination time can be used to aid troubleshooting and/or
by the applications themselves to improve their behavior.
Timestamping can be also used to detect replay attack which are not
addressed in IS-IS currently.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Przygienda, et al. Expires 2 January 2027 [Page 1]
Internet-Draft IS-IS Packet Timestamping July 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Timestamp TLVs . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Adjacency Timestamp TLV . . . . . . . . . . . . . . . . . 5
3.2. LSP Timestamp TLV . . . . . . . . . . . . . . . . . . . . 6
4. Replay Attack Protection . . . . . . . . . . . . . . . . . . 7
4.1. IIH, SNP and ASH Acceptance Rules . . . . . . . . . . . . 8
4.1.1. Recovery Considerations . . . . . . . . . . . . . . . 9
4.2. LSP Acceptance Rules . . . . . . . . . . . . . . . . . . 10
5. Proxy Time Derivation . . . . . . . . . . . . . . . . . . . . 12
6. Operational and Deployment Considerations . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. Yang Extensions for Fragment Timestamping . . . . . . . . . . 14
9.1. Tree for the YANG Data Model . . . . . . . . . . . . . . 14
9.2. YANG Data Model . . . . . . . . . . . . . . . . . . . . . 14
10. Normative References . . . . . . . . . . . . . . . . . . . . 16
11. Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Many applications in today’s networks rely on safe, reliable and
timely flooding of link-state information, such as, but not limited
to Traffic Engineered networks and advanced telemetry solutions. If
such information is delayed during flooding it can be difficult for
those applications to adequately fulfill their intended purpose.
This document describes extensions to ISIS allowing it to carry the
origination time on each packet. The origination time can be used to
aid troubleshooting of large domains and/or by the applications
themselves to improve their behavior. Further, the addition of
timestamps into IS-IS packets allows to address replay attacks.
Thus, IIHs can carry optional timestamps and LSPs will additionally
contain in the timestamp the original lifetime used when originating
the fragment in question.
Przygienda, et al. Expires 2 January 2027 [Page 2]
Internet-Draft IS-IS Packet Timestamping July 2026
As an example, in the case of Traffic Engineered Networks
synchronization of the Traffic Engineering Database (TED) enables the
compute nodes to adapt to changes in the network state and/or react
to network events in a timely manner. If link state information is
delayed during the flooding process this can result in an
unsynchronized TED and easily lead to service degradation due to
substandard re-optimization of network load. More specifically, in
RSVP-TE networks, a TE path computed using a specific snapshot of the
TED may be rejected during signaling by a transit node because of
bandwidth unavailability on a specific link (link bandwidth
information in the snapshot of TED used during computation may not be
“current”). When the ingress is subsequently notified of this
“error” via RSVP signaling, the link in question is avoided in the
subsequent path computation and an alternate path is sought. An
implementation may use a configurable “hold time” to determine how
long this link needs to be avoided. The awareness of the
distribution delay statistics can be used by implementations to
dynamically adapt an appropriate “hold time” for a given TE link
(instead of using a blanket topology-wide configuration). Therefore,
the origination time proposed in this document is meant to be used by
a compute node(s) or by an operator of Traffic Engineered Network to
measure any delays incurred in TED synchronization. The awareness of
delays in the distribution of information can be incorporated further
into algorithms and network tooling to improve the responsiveness and
quality of decisions taken.
As a second application, attackers attempting to replay previously
recorded authenticated exchanges between nodes will be deflected by
the timestamping mechanism refusing to accept packets failing the
required sanity checks. Such a protection relies however on quite
closely synchronized clocks which in itself is an chicken-and-egg
problem given predominant dependency on mechanisms such as NTP
[RFC5905] that rely themselves on forwarding decisions and resulting
server connectivity. This document presents a framework where
adjacencies can be formed using a roughly accurate time derived from
neighbor's precise time before local clock is synchronized fully.
2. Terminology
The following terms are used throughout this document:
Synced Time: A time source on a router that is derived from an
external synchronization mechanism such as NTP [RFC5905], PTP
[IEEEstd1588], or a local hardware clock of sufficient quality
(e.g. a stratum module). A router operating with Synced Time is
considered to have an trustworthy clock for the purposes of this
specification.
Przygienda, et al. Expires 2 January 2027 [Page 3]
Internet-Draft IS-IS Packet Timestamping July 2026
Proxy Time: A time approximation on a router that has no Synced Time
available. Proxy Time is derived from the timestamp carried in an
IIH received from an adjacent neighbor that does possess Synced
Time. Proxy Time is inherently less precise than Synced Time as
it accumulates the precision error of the source plus any
propagation delay on the link. A router operating with Proxy Time
MUST reflect this reduced precision in the Precision field of any
timestamps it originates. Proxy time MUST NOT be derived from any
other packet than neighbor's IIH.
Adjacency Timestamp: A timestamp carried in the Adjacency Timestamp
TLV, used in IIH, SNP, and ASH packets. A node without a usable
time source MUST NOT include this TLV.
LSP Timestamp: A timestamp carried in the LSP Timestamp TLV, used
exclusively in LSP fragments. It indicates the point in time the
fragment with its current sequence number was generated and
optionally carries the originating lifetime. A node without a
usable time source MUST NOT include an LSP Timestamp TLV.
Valid Timestamp: A timestamp that passes the applicable acceptance
rules defined in this document. Only a Valid Timestamp may be
used for replay protection decisions or Proxy Time derivation.
Invalid Timestamp: A timestamp that fails the applicable acceptance
rules. A packet bearing an Invalid Timestamp is subject to the
rejection or hold-down procedures specified in the relevant
acceptance section.
3. Timestamp TLVs
This section defines two new, optional TLVs for carrying timestamps
in ISIS packets. The two TLVs are distinguished by type code: the
Adjacency Timestamp TLV is used in IIH, SNP, CSNP, and ASH packets,
while the LSP Timestamp TLV is used exclusively in LSPs and carries
the originating lifetime of the fragment. In case of multiple
instances of a timestamp TLV in a packet are present, the first one
MUST be processed, and any later ones MUST be ignored. The absence
of a timestamp TLV signifies that the node does not have a usable
time source or does not support timestamping at all.
A node that includes a timestamp TLV MUST ensure that the time value
carried is strictly monotonically increasing across successive
packets of the same type on the same adjacency (for Adjacency
Timestamps) and monotonically for the same LSP fragment (for LSP
Timestamps). An implementation MUST NOT send a timestamp with a
value equal (and for Adjacency Timestamp also less than) to the last
timestamp it sent in the same context, even if the local clock is
Przygienda, et al. Expires 2 January 2027 [Page 4]
Internet-Draft IS-IS Packet Timestamping July 2026
adjusted backwards. In such cases the implementation MUST hold off
sending until the clock advances until it reaches an acceptable
value.
Both TLVs share a common time encoding. To save space the timestamp
follows semantically the NTP seconds epoch [RFC5905] with the
exception of an extra bit in the seconds field to extend the wrap
around and carrying approximately 1 millisecond resolution in the
fractional part of the timestamp since this is considered sufficient
for link-state purposes. The specification follows further
guidelines of [RFC8877] as far as possible.
3.1. Adjacency Timestamp TLV
When present in an IIH, SNP, CSNP, or ASH packet, this TLV carries
the origination time of the packet. A node without a usable time
source MUST NOT include this TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H|P| Fraction | Precs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
* Type: TBD1
* Length: 6 (fixed).
* Seconds: 4 bytes of number of seconds since the NTP [RFC5905]
epoch.
* H(-Bit): 1 bit. Extra high order bit is used to prevent wrap-
around in 2036 and pushes it out to 2242. The offset can be
constructed in network order as 33rd bit of a 64 bits value and
the `Seconds` field OR'ed into the lower order bits of the
according value.
* P(-Bit): 1 bit. Proxy Time indicator. When set to 0, the
originator is using Synced Time (as defined in Section 2). When
set to 1, the originator is using Proxy Time derived from
neighbors' IIH timestamps.
Przygienda, et al. Expires 2 January 2027 [Page 5]
Internet-Draft IS-IS Packet Timestamping July 2026
* Fraction: 10 bits representing the fractional part of the second
linearly in units of 2^-10 seconds which is equivalent to
approximately 1 millisecond resolution. The value MUST be less
than 1024. Any value greater than 1024 MUST be treated as 1024
milliseconds. For example, a fraction value of 3 represents
3/1024 seconds ≈ 2.93 milliseconds and a value of 4 represents
4/1024 seconds ≈ 3.91 milliseconds, demonstrating sub-millisecond
step granularity.
* Precision: 4 bits indicating the maximum possible slip (either in
future or past) of the time source used to generate the timestamp
as 2^Precision milliseconds. The time source may be a
synchronization protocol (such as NTP or PTP), a local hardware
clock (such as a stratum 0 receiver), or an internal oscillator.
The advertised value MUST reflect the worst-case accuracy
achievable by whatever mechanism provides the time. This yields a
range from 1 millisecond (value 0) to 32768 milliseconds (value
15). Values resulting in precision worse than 1024 milliseconds
MUST be treated as indicating 1024 milliseconds by the receiver.
For example, a precision value of 1 indicates 2^1 = 2 milliseconds
maximum slip and a value of 2 indicates 2^2 = 4 milliseconds
maximum slip. A node that cannot achieve a precision of 1024
milliseconds or better MUST NOT include this TLV.
3.2. LSP Timestamp TLV
When contained in a fragment this TLV indicates the point in time the
fragment with the current sequence number has been generated and
carries the original lifetime used. A node without a usable time
source MUST NOT include this TLV.
For practical purposes, although desirable, timestamping the moment a
fragment is flooded would be preferable but beside practical
implementation problems this could generate on different interfaces
the same fragment with different content which breaks one of the
fundamental tenants of link-state protocols. However, an
implementation is free to choose to use, e.g. the moment the fragment
is queued for flooding first time rather than the time the version is
generated.
Przygienda, et al. Expires 2 January 2027 [Page 6]
Internet-Draft IS-IS Packet Timestamping July 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H|P| Fraction | Precs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Lifetime |
+-------------------------------+
Figure 2
* Type: TBD2
* Length: Constant of 8 bytes.
* Seconds, H-Bit, P-Bit, Fraction, Precision: Equivalent to the
Adjacency Timestamp TLV (see Section 3.1). A node that cannot
achieve a precision of 1024 milliseconds or better MUST NOT
include an LSP Timestamp TLV.
* Originating Lifetime: Indicates the value of the LSP remaining
lifetime field when the LSP was originated.
4. Replay Attack Protection
The timestamp field MUST NOT be used if the packet is not
authenticated by cryptographic signature or hash. Further
considerations are outlined in Section 7.
Packets arriving on the wire SHOULD undergo timestamp sanity checking
as soon as possible after being cryptographically authenticated.
The following intervals are used throughout this section:
|P (Proxy Allowance): When a received timestamp has the P-Bit set
(indicating Proxy Time as defined in Section 2), a constant not
smaller than 1 second MUST be added to the indicated precision
before computing |S or |L. This accounts for the inherent
inaccuracy of a clock derived from a neighbor's timestamp rather
than a direct synchronization source.
|S (Small Delta): The interval of (indicated precision in the packet
+ local precision) multiplied by a small constant + |P if P-Bit is
set. Used for validating IIH and SNP timestamps where tight clock
accuracy is expected.
Przygienda, et al. Expires 2 January 2027 [Page 7]
Internet-Draft IS-IS Packet Timestamping July 2026
|L (Large Delta): The interval of (indicated precision in the packet
+ local precision ) multiplied by a larger constant + |P if P-Bit
is set. Used for LSP lifetime validation where coarser time
resolution applies. For practical purposes |L is likely to span
several seconds.
When timestamped, packets can be protected against replay attacks by
following acceptance rules.
4.1. IIH, SNP and ASH Acceptance Rules
A node MUST track per adjacency the timestamp value last accepted
from the neighbor (the "last-iih-timestamp-seen", "last-snp-
timestamp-seen" and "last-ash-timestamp-seen"). All these values are
reset when the adjacency transitions to Down state.
The following rules govern acceptance of IIH, SNP and ASH packets
with respect to timestamping:
1. When the adjacency transitions to Down state, last seen
timestamps MUST be cleared.
2. While the adjacency is in Down state and last-iih-timestamp-seen
is not set, an IIH without the Adjacency Timestamp TLV is
accepted (subject to normal IS-IS authentication). An IIH
carrying an Adjacency Timestamp TLV with a timestamp deviating
more than |S from the local clock (accounting for |P if the P-Bit
is set) MUST be dropped. If the TLV is present and the timestamp
is within |S, last-iih-timestamp-seen is set to the received
timestamp value. Same rule applies for SNP and ASH packets while
using the corresponding variable.
3. Once last-*-timestamp-seen is set, the corresponding packet
received without the Adjacency Timestamp TLV MUST be silently
dropped.
4. Once last-*-timestamp-seen is set, a packet carrying a timestamp
less than or equal to last-*-timestamp-seen MUST be silently
dropped.
5. Once last-*-timestamp-seen is set, a packet carrying a timestamp
deviating more than |S from the local clock (accounting for |P if
the P-Bit is set) MUST be dropped.
6. A packet carrying a Valid Timestamp (greater than last-*-
timestamp-seen and within |S of the local clock and accounting
for |P if the P-Bit is set) MUST be accepted and last-*-
timestamp-seen MUST be updated to the received value.
Przygienda, et al. Expires 2 January 2027 [Page 8]
Internet-Draft IS-IS Packet Timestamping July 2026
7. If last-iih-timestamp-seen is set and no valid packet has been
accepted for the duration of the adjacency hold period, all
last-*-timestamp-seen MUST be cleared. This covers the case
where a neighbor issued timestamps and then rebooted without a
clock, preventing a permanent lockout on that adjacency.
4.1.1. Recovery Considerations
Clearing last-iih-timestamp-seen on transition into Down state is not
sufficient to prevent permanent lockout. Consider the following
scenario: the adjacency is already in Down state, a valid timestamped
IIH arrives from the neighbor (setting last-iih-timestamp-seen), and
the neighbor then reboots without support of timestamping. The
rebooted neighbor now sends IIHs without the Adjacency Timestamp TLV
forever, which are dropped because last-iih-timestamp-seen is set.
Since the adjacency is already Down, no hold timer is running to
expire it and trigger a fresh Down transition that would clear the
value. The adjacency is permanently stuck.
The inactivity reset rule above resolves this: if no valid
timestamped packet is accepted within the hold period (regardless of
adjacency state), last-*-timestamp-seen variables are cleared
unconditionally. This allows the adjacency formation to proceed once
the rebooted neighbor resumes sending IIHs (with or without
timestamps).
When a node reboots and has lost its clock, the neighbor's last-iih-
timestamp-seen still holds the value from before the reboot. The
rebooted node cannot send a timestamp higher than this value because
it has no time source. Two recovery paths exist:
* The neighbor's adjacency hold timer expires (no valid IIHs
accepted), the adjacency transitions to Down, last-*-timestamp-
seen variables are cleared, and the 3-way handshake proceeds
normally once the rebooted node acquires a clock.
* The rebooted node derives Proxy Time from a received IIH on the
same or another interface. Since time always advances, the
derived Proxy Time will be higher than any previously sent
timestamp. The node can then send an IIH with this Proxy Time
which will be accepted by the neighbor (it is greater than last-
iih-timestamp-seen), allowing the adjacency to recover without
waiting for the hold timer.
Przygienda, et al. Expires 2 January 2027 [Page 9]
Internet-Draft IS-IS Packet Timestamping July 2026
4.2. LSP Acceptance Rules
The following diagrams illustrate the temporal relationships between
originating timestamp, originating lifetime, LSP remaining lifetime,
and the acceptance window. We use the term time-in-transit to
indicate (originating lifetime - current lsp lifetime).
Normal LSP in transit:
orig_ts now orig_ts + orig_lifetime
| | |
|=================================|=======================|
|<--- elapsed since origination ->|<-- lsp_lifetime ----->|
| | |
|<-------------- orig_lifetime (from Timestamp TLV) ----->|
Invariant: orig_ts + orig_lifetime - lsp_lifetime ≈ now
(the difference is propagation delay + processing)
Figure 3
Acceptance window for (orig_ts + lsp_lifetime):
|L| now |L|
<-> | <->
REJECT |<============ ACCEPT WINDOW ===============>| REJECT
| |
| now - L now + L |
- orig_ts + time-in-transit must fall within [now - |L, now + |L]
- lsp_lifetime must be ≤ orig_lifetime
- orig_ts + time-in-transit must be > last accepted timestamp (strictly monotonic)
Figure 4
A node MUST track per LSP fragment the timestamp value last accepted
as the "last-fragment-timestamp-seen". This variable is set when a
timestamped fragment is accepted and is used to enforce monotonicity
across successive instances of the same fragment. If a newer,
authenticated fragment (as determined by standard IS-IS fragment
comparison rules) arrives without an LSP Timestamp TLV, it MUST be
accepted normally and last-fragment-timestamp-seen MUST be cleared
for that fragment. This covers the case of a node that was
downgraded or lost its clock and is re-originating without
timestamps. To prevent a chain of attacks with pre-recorded higher
fragment version numbers without timestamps a node MAY decide to
issue timestamped newer versions the fragment with a large increment
in case of such an attack.
Przygienda, et al. Expires 2 January 2027 [Page 10]
Internet-Draft IS-IS Packet Timestamping July 2026
When timestamped, LSPs packets which are not purges and trigger any
of the criteria corresponding to Figure 4 acceptance window failure
1. LSP lifetime larger than originating lifetime
2. (originating timestamp + time-in-transit) deviating more than |L
from current local time
3. (originating timestamp + time-in-transit) smaller than last-
fragment-timestamp-seen (except purges)
SHOULD not be accepted.
The last condition allows specifically for sending multiple versions
of a fragment with the same timestamp within a small window of time.
Attempts to tighten this further would limit the maximum rates of
packet issuance given the timestamp resolution and impose further
very strict packet queuing limitations. An attempted replay attack
within this window is detectable by arrival of excessive amount of
versions of the same fragment within a small window of time and
should be tracked and reported.
Purging presents a particularly difficult problem since [RFC6232]
mandates the acceptable TLVs in a purge and timestamping is currently
not part of those TLVs. Due to this precondition, a change in
standard is needed and timestamping on purging can only be originated
after upgrade of the whole domain. Additionally, purges carry a
lifetime of 0 which defeats the timestamp criteria as defined above
and thus need a different set of rules. Purges that trigger any of
the criteria
1. If last-fragment-timestamp-seen is set, a purge without an LSP
Timestamp TLV MUST be rejected.
2. timestamp contains originating lifetime different from 0.
3. (originating timestamp + |L) is in the future compared to current
local time
4. originating timestamp less or equal to the timestamp seen on the
last purge for this LSP
5. originating timestamp smaller than last-fragment-timestamp-seen
SHOULD be discarded.
Przygienda, et al. Expires 2 January 2027 [Page 11]
Internet-Draft IS-IS Packet Timestamping July 2026
5. Proxy Time Derivation
A node that has not yet synchronized a precise internal clock (e.g.
has not acquired NTP synchronization) SHOULD derive its Proxy Time
from its adjacent neighbors' IIH timestamps using the following
algorithm:
1. Collect periodically the most recent accepted IIH timestamp from
each neighbor that has P=0 (Synced Time). Timestamps with P=1
MUST be excluded from Proxy Time derivation to prevent
compounding of inaccuracies through successive diffusion of
proxy-derived clocks across multiple hops. The acceptance rules
for IIHs when using or deriving a proxy time is relaxed to only
check for authentication and monotonicity against current proxy
time. The proxy time can be used to set a local clock source
progressing the proxy time or otherwise must be derived often
enough to not trigger sent IIH acceptance rules and resulting
discard on the receivers.
2. Compute the median of these collected timestamps. Using the
median rather than the average ensures that an attacker
controlling a minority of adjacencies cannot skew the derived
Proxy Time. In case of even amount of samples, the value one
above the index of 1/2 of the samples must be used to prevent
attacks when only 2 adjacencies are established. This thwarts
replay attackers controlling fewer than 50% of the eligible
adjacencies.
3. The new Proxy Time is set to: max(current Proxy Time, computed
median). When updating the proxy time with new median maximum of
its precision and precision of local source SHOULD be used to
advertise with the proxy time. Proxy Time MUST never decrease.
This monotonicity constraint prevents a skew-down attack in which
an adversary replays old (but once-valid) timestamps on a newly-
formed adjacency in an attempt to pull the proxy clock backwards.
The combination of median selection and monotonic advancement
provides Byzantine-fault-tolerant proxy derivation: an attacker must
compromise more than half the eligible adjacencies of a node to
influence its Proxy Time at all, and even then cannot move it
backwards.
A node operating with Proxy Time MUST set the P-Bit on all timestamps
it originates (in IIHs, SNPs, ASHs and LSPs).
Przygienda, et al. Expires 2 January 2027 [Page 12]
Internet-Draft IS-IS Packet Timestamping July 2026
6. Operational and Deployment Considerations
A requirement for the correct interpretation of the additions
proposed in this document is an infrastructure capable of
synchronizing time across devices involved so the timestamps at the
various points of interest become comparable. This could be
accomplished by utilizing NTP [RFC5905], Precision Time Protocol
(PTP) IEEE Std. 1588 [IEEEstd1588] or 802.1AS [IEEEstd8021AS]
designed for bridged LANs. The achieved precision is carried in the
timestamp of the fragment.
Though the timestamp can be very useful in deriving measurement of
behavior in a deployed IS-IS network, e.g. maximum incurred flooding
delays between any pair of nodes, it should not be used in any
attempts to modify the behavior of protocol behavior itself such as
e.g. influencing flooding rates. A single badly synchronized clock
could otherwise change the behavior of parts or even the whole
network in unpredictable or even detrimental way. Replay protection
as defined in Section 4 is an exception.
7. Security Considerations
For practical reasons, the timestamping replay protection defined in
this document relies on strictly monotonically increasing timestamps
rather than negotiation and repetition of nonces. It preconditions
clock synchronization across nodes and hence presents an attack
vector where the necessary clock mechanisms can be compromised if
vulnerable. The attack windows and vectors are otherwise comparable
due to the nature of IGPs which do not rely on lossless communication
channels.
The replay protection mechanisms defined in this document rely on the
IS-IS three-way handshake as defined in [RFC5303] to prevent an
attacker from exploiting adjacency state transitions to reset
timestamp tracking state. Accordingly, IS-IS three-way handshake
MUST be deployed on all interfaces and cryptographic authentication
MUST be enabled before timestamping is used for replay attack
protection. If either precondition is not met, IIH timestamps MUST
NOT be relied upon for replay protection and SHOULD be used for
informational purposes only. LSP replay protection as defined in
this document does not depend on the three-way handshake but MUST
only be employed when cryptographic authentication of LSPs is
enabled.
8. Acknowledgments
TBD
Przygienda, et al. Expires 2 January 2027 [Page 13]
Internet-Draft IS-IS Packet Timestamping July 2026
9. Yang Extensions for Fragment Timestamping
9.1. Tree for the YANG Data Model
This document uses the graphical representation of data models per
[RFC8340].
The following shows the tree diagram of the module:
module: ietf-isis-fragment-timestamping
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis
/isis:database/isis:levels/isis:lsp:
+--rw fragment-origination-time? yang:date-and-time
9.2. YANG Data Model
The following is the YANG module:
<CODE BEGINS> file "ietf-isis-fragment-timestamping@2026-06-26.yang"
module ietf-isis-fragment-timestamping {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-isis-timestamping";
prefix isis-fragment-timestamping;
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-routing {
prefix rt;
reference
"RFC 8349: A YANG Data Model for Routing
Management (NMDA Version)";
}
import ietf-isis {
prefix isis;
reference
"RFC 9130: YANG Data Model for the IS-IS Protocol";
}
organization
"IETF LSR - LSR Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/lsr>
WG List: <mailto:lsr@ietf.org>
Przygienda, et al. Expires 2 January 2027 [Page 14]
Internet-Draft IS-IS Packet Timestamping July 2026
Author: Renato Westphal
<renato@netdef.org>
";
description
"The YANG module augments the base IS-IS YANG data model with
operational state related to IS-IS fragment timestamping.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
reference
"RFC XXXX: Optional IS-IS Fragment Timestamping";
revision 2026-06-26 {
description
"Initial Version";
reference
"RFC XXXX: Optional IS-IS Fragment Timestamping";
}
/* Fragment Timestamp TLV */
augment "/rt:routing/"
+ "rt:control-plane-protocols/rt:control-plane-protocol"
+ "/isis:isis/isis:database/isis:levels/isis:lsp" {
when "derived-from-or-self(../../../../rt:type,"
+ "'isis:isis')" {
description
"This augment ISIS routing protocol when used";
}
description
"This augments IS-IS protocol LSDB with Timestamp TLV.";
Przygienda, et al. Expires 2 January 2027 [Page 15]
Internet-Draft IS-IS Packet Timestamping July 2026
leaf fragment-origination-time {
type yang:date-and-time;
description
"The time at which this LSP fragment with the
current sequence number was generated.";
}
}
}
<CODE ENDS>
10. Normative References
[IEEEstd1588]
IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
IEEE Standard 1588,
<https://ieeexplore.ieee.org/document/4579760/>.
[IEEEstd8021AS]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Timing and Synchronization for Time-Sensitive
Applications in Bridged Local Area Networks",
IEEE Standard 802.1AS,
<https://ieeexplore.ieee.org/document/5741898/>.
[RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way
Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303,
DOI 10.17487/RFC5303, October 2008,
<https://www.rfc-editor.org/info/rfc5303>.
[RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge
Originator Identification TLV for IS-IS", RFC 6232,
DOI 10.17487/RFC6232, May 2011,
<https://www.rfc-editor.org/info/rfc6232>.
11. Informative References
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
Przygienda, et al. Expires 2 January 2027 [Page 16]
Internet-Draft IS-IS Packet Timestamping July 2026
[RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
Defining Packet Timestamps", RFC 8877,
DOI 10.17487/RFC8877, September 2020,
<https://www.rfc-editor.org/info/rfc8877>.
Authors' Addresses
Tony Przygienda
HPE Juniper Networking
Email: antoni.przygienda@hpe.com
Colby Barth
HPE Juniper Networking
Email: colby.barth@hpe.com
Tony Li
HPE Juniper Networking
Email: anthony.li@hpe.com
Joel Halpern
HPE Juniper Networking
Email: joel.halpern@hpe.com
Przygienda, et al. Expires 2 January 2027 [Page 17]