Subject: Re: [Isis-wg] [karp] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00

From: Manav Bhatia <[email-masked]>
Date: Sat, 31 Mar 2012 03:41:09 +0100 (BST)

And this is precisely the reason why crypto sequence numbers were not added when we did RFC 5310.

Cheers, Manav

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Les Ginsberg (ginsberg)
> Sent: Friday, March 30, 2012 11:34 PM
> To: Uma Chunduri; Naiming Shen (naiming)
> Cc: Mike Shand; [email-masked]; [email-masked]
> Subject: Re: [karp] [Isis-wg] Question 
> regardingdraft-chunduri-isis-extended-sequence-no-tlv-00
> 
> Uma -
> 
> It seems likely that we simply disagree.
> 
> In summary as regards use of the extended sequence # in LSPs, I am 
> saying you are trying to address a potential attack which is extremely 
> unlikely to occur and for which, should it occur, the protocol already 
> has a reliable means of recovering. I therefore feel this extension is 
> not needed for LSPs.
> 
> I will start another thread shortly regarding SNPs and hellos.
> 
>   Les
> 
> 
> > -----Original Message-----
> > From: Uma Chunduri [mailto:[email-masked]]
> > Sent: Friday, March 30, 2012 3:13 AM
> > To: Les Ginsberg (ginsberg); Naiming Shen (naiming)
> > Cc: Mike Shand; [email-masked]; [email-masked]
> > Subject: RE: [Isis-wg] 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
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
> 
_______________________________________________
karp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/karp