Re: Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00

Hi Les,

My replies in-line [Uma]
-- 
Uma C. 

> 
> Uma -
> 
> The response you make below does not address the points raised by Mike
and
> myself. It is understood that the difference between one version of a 
> given LSP and another may be small or large
in terms
> of the number of TLVs that have changed.
> This point was not mentioned at all by Mike or myself.
> Here is a summary of the concerns we raised:
> 1)LSPs already have a built in sequence number which allows ISs to
recognize
> a valid but stale version of an LSP
> 
> [Uma]: No, ISs can't recognize stale version, if this is replayed from
the
> previous session. I guess, we have clearly mentioned this in the
document.
> 
This is not correct.
What happens is that the LSP with higher sequence number will get propagated until it reaches the originator.
[Uma]: ... and all the node who processed and acted on this replay are impacted. You can't precisely
quantify, 
how long and what impact.

The originator will recognize that this LSP is "owned" by itself but looks "newer" (based on sequence #) 
than what is in its local database. It will immediately generate a new version of the LSP with higher 
sequence # and flood that - which will replace any versions of the replayed LSP which exist in the network.

[Uma]: Now you are talking about the recovery mechanism which is kicked in by the originator in this situation.

Essentially you originally stated - "LSPs already have a built in sequence number which allows ISs to
recognize a valid but stale version of an LSP". When I disagreed on this you are talking about in built
recovery mechanism.
I would only guess this is the gap, causing you to believe the new TLV which allow you to recognize the replay
and drop 
has low ROI.

Depending on where in the network the attacker injects the replayed LSP will influence the response time of
the originating node - but the 
replayed LSP will be replaced in a timely fashion without any extensions to the protocol.

[Uma] Precisely. "Depending on where in the network" replayed LSP will influence the response and in the
mean time as I 
said our FC timers kick-in all the nodes act on this replay (Eg: yeah, my backlink check failed and removing
all the prefixes 
corresponding to the same). It's good this situation is recoverable eventually, but the point is you  are 
already impacted. Not only you and *all_nodes* in the network are impacted ( I mentioned this earlier and I
am repeating).

Please consult ISO 10589 Section 7.3.15.1 (c) and (d) as well as Sections 7.3.16.1 and 7.3.16.4.

> 2)Normal operation of the Update Process recovers from the presence of
a
> stale but valid LSP quickly (in tens to hundreds of milliseconds) by
having
> the originator regenerate its LSP with higher sequence #. This is a
scenario
> which is encountered in normal operation following a restart and is
handled
> correctly and promptly today.
> 
> [Uma]: This need not be *always* TRUE. Of course, the above happens
only if
> the networks still has the restarted IS's LSP/LSP-fragments still not
aged
> out.

Agreed.
My point is only that the protocol handles this situation today and it can be easily demonstrated.

> 
> 3)The replay scenario discussed in the thread postulated that an
attacker
> could store many old LSPs and replay them one at a time. For this
attack to
> be possible all of the following conditions would need to be met:
> a) Attacker stores "many" LSPs without knowing whether a system will
ever
> restart and if it does when that restart will occur - which could be
months
> or years later
> b)A system shuts down and does not restart until all of its LSPs have
aged
> out of the network - which can be up to 18 hours depending on the
configured
> value for LSP Maxage
> c)After a system restarts the attacker recognizes that the system has 
> restarted and replays each of the stored LSPs with some discrete time 
> interval between replays Should all of the conditions be met it would 
> still be true that the
replay of
> any version of a given LSP would only cause
> 
> [Uma]: The above conditions are not impossible for an attacker (by
definition
> an adversary is absolutely motivated)

Agreed.
But my point is to highlight that an attack of this sort is unlikely to occur and if it does the damage done will
be short-lived and not persistent.

> 
> a short disruption as the base protocol mechanisms mention in #2 above
would
> provide quick recovery.
> 
> [Uma]: Again "short"?? I would only say it depends.. As I mentioned
earlier,
> in #2 you are assuming you always have the restarted IS's
LSP/LSP-fragments
> not aged out.

No - I am not making that assumption. I am saying that in order for the attack to have any impact the restarted
LSPs must have aged out. I think we agree on that.

>        After IS restart or brought back in service, for any potential
replay
> *all* nodes in the network have to flap the routes.
>        This can happen multiple times to multiple LSP fragments
(depending on
> how these are replayed) and every time all nodes
>        in the network are impacted which ever process the replay.
> 
> All of the above raises the question as to whether extended sequence #
is
> needed in LSPs given the scenarios in which it adds any value at all
are
> severely limited and the value it adds is also limited i.e. the
protocol will
> recover even in the absence of the extended sequence number and will
do so
> quickly
> Could you please respond to the above?
> 
> [Uma] Hope I clarified above and again the word "quickly" is
subjective in
> the example I provided.

The discussion I want to have is an evaluation of the "return on investment(ROI)" of this extension. Every
protocol extension comes with costs. These include the costs of developing the extension, supporting
the extension, deploying the extension, and the overhead of processing the extension in each PDU. The
enthusiasm for any proposal is proportional to the ROI. Right now, I am seeing a very low ROI in this case.

[Uma]: I would only say, just because we  have an in-built recovery, you can't assume a mechanism which
mitigates this threat in first place has low ROI. And coming to the solution,  this optional TLV introduce
neither complexity nor introduce significant overhead in processing. So I didn't quite understand your
claim of "low" ROI.

   Les

> 
> There are then additional discussions to be had regarding the
usefulness of
> the extended sequence # in SNPs and hellos - but let's leave that to
another
> thread.
> 
> [Uma] Sure, the additional discussion on the other messages are
equally
> important and we need your feedback/comments.
> 
> 
> Thanx.
> 
>    Les