Folks -
This draft replaces the earlier https://datatracker.ietf.org/doc/draft-rigatoni-lsr-isis-fragment-timestamping/ . 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 - 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://datatracker.ietf.org/doc/rfc7602/> - IS-IS Extended Sequence Number TLV rfc7645<https://datatracker.ietf.org/doc/rfc7645/> - 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 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]
