Les, as you say, yes, it’s an individual draft. Expect surprises while we work through problems and solutions while socializing things and implementing them 😉
RFC 7602<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc7602/__;!!NpxR!gvHnr-99DNfKYdLHR2pwFPxaCxELcSE_3kneUwyWwC0H2XDucxi8yl-RRIxVzwcgtbqQYTfToCts7owMm8ne$> - IS-IS Extended Sequence Number TLV I sent you a private message, AFAIS this is a very, very weak security mechanism although I deny that the timestamping replay covering more attacks has its own warts (clock) rfc7645<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc7645/__;!!NpxR!gvHnr-99DNfKYdLHR2pwFPxaCxELcSE_3kneUwyWwC0H2XDucxi8yl-RRIxVzwcgtbqQYTfToCts7vCYtldj$> - The Keying and Authentication for Routing Protocol (KARP) IS-IS Security Analysis Saying something like “LSPs will recover” is not a security strategy, it’s a hopeful statement at best so I tried to address that. However, there is no viable way to completely secure LSPs unless we force it to the point that after a timestamped/secured fragment no version w/o timestamp are accepted. Otherwise someone who recorded a seq# flip over can run an attack ad infinitum with the packets recorded (I assume you can think that through easily). If the WG however agrees overall that fixing LSPs replay is not worth it and we should just rely on hellos (peering scope security) then we can work with nonces since they would fit into IIH/SNP and then we can basically copy RFC9692 which is based on last 30 years research on IGP security while moderated by practical experience of what’s doable. This will fix pretty much all viable attack vectors (bare BW attacks etc) on hellos/snps/ashes unless I miss something. — Tony Sent from Outlook for Mac From: Les Ginsberg (ginsberg) <[email protected]> Date: Monday, 20 July 2026 at 23:26 To: [email protected] <[email protected]>; lsr <[email protected]> Subject: Discussion of draft-many-lsr-isis-packet-timestamping Folks - This draft replaces the earlier https://datatracker.ietf.org/doc/draft-rigatoni-lsr-isis-fragment-timestamping/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-rigatoni-lsr-isis-fragment-timestamping/__;!!NpxR!gvHnr-99DNfKYdLHR2pwFPxaCxELcSE_3kneUwyWwC0H2XDucxi8yl-RRIxVzwcgtbqQYTfToCts7i8rwBIu$> . What I found surprising - partially because I had not yet read the updated draft - is that the focus of the draft significantly changed. Draft-rigatoni focused on the use case for: * measure flood delays across diameter, max/deviation/etc * measure on TED database how quickly information from nodes propagates to * allow better optimization of TE under congestion * be able to indicate when a node issued the last fragment (stability of network) (Note: These bullet points are from https://datatracker.ietf.org/meeting/120/materials/slides-120-lsr-isis-fragment-timestamping-01<https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/120/materials/slides-120-lsr-isis-fragment-timestamping-01__;!!NpxR!gvHnr-99DNfKYdLHR2pwFPxaCxELcSE_3kneUwyWwC0H2XDucxi8yl-RRIxVzwcgtbqQYTfToCts7pikC60j$> - which was the last time the draft was presented.) Now the draft /presentation is focused on replay. Indeed, the word “replay” appears 16 times in the latest draft – but appears not at all in previous versions. Tony – you certainly have the right to change direction – especially since this is an individual contribution - but this did catch me by surprise . 😊 As regards past discussion about replay and IS-IS, the following references are relevant: RFC 7602<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc7602/__;!!NpxR!gvHnr-99DNfKYdLHR2pwFPxaCxELcSE_3kneUwyWwC0H2XDucxi8yl-RRIxVzwcgtbqQYTfToCts7owMm8ne$> - IS-IS Extended Sequence Number TLV rfc7645<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc7645/__;!!NpxR!gvHnr-99DNfKYdLHR2pwFPxaCxELcSE_3kneUwyWwC0H2XDucxi8yl-RRIxVzwcgtbqQYTfToCts7vCYtldj$> - The Keying and Authentication for Routing Protocol (KARP) IS-IS Security Analysis There is also the discussion on the (then) IS-IS WG list. Here’s a pointer to some of that discussion: https://mailarchive.ietf.org/arch/browse/isis-wg/?gbt=1&index=N_lEZcMTeNCeuu1-8pZQQVsNhrY<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/isis-wg/?gbt=1&index=N_lEZcMTeNCeuu1-8pZQQVsNhrY__;!!NpxR!gvHnr-99DNfKYdLHR2pwFPxaCxELcSE_3kneUwyWwC0H2XDucxi8yl-RRIxVzwcgtbqQYTfToCts7hnYfddl$> Much of that discussion considered the existing resilience of LSPs to replay attacks and the problems associated with introducing a new replay mechanism into LSPs – especially considering partial deployment. This is why RFC 7602 intentionally does not apply to LSPs. HTH Les
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
