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

From: Uma Chunduri <[email-masked]>
Date: Thu, 29 Mar 2012 04:50:38 -0400

[CC'ed KARP too]

In the ISIS wg meeting in Paris, we addressed the concerns raised by Les and Mike in the mailing list.
As asked by chairs we are summarizing here, the points briefly discussed specifically on the ESN TLV in LSP.

- Though, the originator updates the sequence number and floods the same when replay is received,
  the impact of the replayed LSP in the network  *purely* depends on the content of the replayed packet
  (this could be fewer TLV22s/222s or ..) and also all the nodes in the area/domain could be impacted.
     - plz note an adversary can potentially do this for any LSP fragment of a particular node/any node.
- As rightly pointed by Mike, on the 18hrs max age configuration 
     - if a node/card in the network need to be serviced one can't assume always this can be done 
       in this time 
     - Still ISO default MAXAGE (20mins) is seen in the deployments
     - In this sense as Naiming indicated if this optional TLV protection is needed or not 
       could be decided by the operator. 
-- 
Uma C. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, October 27, 2011 6:26 PM
To: Naiming Shen (naiming)
Cc: Mike Shand; [email-masked]
Subject: Re: [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00

Naiming -

> -----Original Message-----
> From: Naiming Shen (naiming)
> Sent: Thursday, October 27, 2011 6:18 PM
> To: Les Ginsberg (ginsberg)
> Cc: Mike Shand; [email-masked]
> Subject: Re: [Isis-wg] Question regardingdraft-chunduri-isis-extended-
> sequence-no-tlv-00
> 
> 
> My opinion is this:
> 
> - We know we need to have this TLV in non-LSP ISIS packets for obvious
>    reasons

I don't think we have consensus on this yet. I have other concerns regarding SNPs and IIHs which I have not yet raised as I thought it would be easier to discuss one PDU at a time. :-)

I also think Manav has raised an excellent point and would like to see his question addressed.

> - We know there is a security hole even with LSP which already has
>    seq# and authentications, it does not matter how small the hole is.

I think this is also debatable. Changes to the protocol come at a cost - both to the protocol vendors and the users of the protocol. I do not share your opinion that all potential security issues have to be addressed. A prudent evaluation of the risks and the costs needs to be made.

   Les

>    thus we probably should not say this TLV is not allowed in the LSP 
> packet
> - Operators can make this decision (to use this TLV or not inside the 
> LSP packet)
>   base on whatever they see their network security requirements
> 
> - Naiming
> 
> On Oct 27, 2011, at 5:38 PM, Les Ginsberg (ginsberg) wrote:
> 
> > I started this thread to ask what value add the new TLV has when
used
> in
> > LSPs. So far, the discussion has focused on a corner case wherein:
> >
> > a)The attacker needs to store old LSPs in the hopes that the
> originating
> > router will be shutdown sometime in the future - a time which may be 
> > weeks or months after the attacker begins collecting the old LSPs
> >
> > b)The router to be attacked must shutdown for a period greater than
> LSP
> > lifetime
> >
> > c)The attacker must notice that the router to be attacked has
> shutdown
> > and wait for LSPs to be aged out from all routers in the network
> >
> > IF all of the above are met the attacker may then cause disruption
> for a
> > period of time which is proportional to the number of old LSPs it
has
> > stored - and the disruption period associated with each LSP version 
> > would be a modest period.
> >
> > Now, is this the sole usefulness of the new TLV in LSPs? AFAICT it
is
> -
> > but I am asking the authors to speak to this point in case I have 
> > overlooked something.
> >
> > If this is the sole use case for the new TLV in LSPs, then I think a 
> > legitimate question is whether this is a problem worth solving. The 
> > "security hole" can only be used on rare occasions and  isn't
> guaranteed
> > to provide any opportunity to cause disruption (the router which is 
> > shutdown may be taken out of service permanently - or be restarted
> with
> > a new identity - or not be out of service long enough to allow old
> LSPs
> > to be aged out) and the duration of the disruption is bounded even
on
> > those rare occasions when the opportunity presents itself. This
isn't
> a
> > compelling justification.
> >
> >   Les
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of Naiming Shen (naiming)
> >> Sent: Thursday, October 27, 2011 3:13 PM
> >> To: Mike Shand
> >> Cc: [email-masked]
> >> Subject: Re: [Isis-wg] Question regardingdraft-chunduri-isis-
> extended-
> >> sequence-no-tlv-00
> >>
> >>
> >> Hi Mike,
> >>
> >> You are correct of course. I was just saying this 30 seconds the
> > hacker
> >> does not have
> >> to follow this 300ms timing, and he/she can set this as a 30
seconds
> >> fixed interval to release the
> >> next attack packet. Also the network routers have hold down timers
> for
> >> SPFs and they may
> >> not react to changes immediately. Even if they do, we will see the 
> >> network traffic disrupted for every 30 seconds briefly for 2 days 
> >> in this example.
> >>
> >> We can change the parameters also, instead of capturing for 3
> months,
> >> he/she can do for years.
> >> Or the hacker can cause some link change events to force your
router
> > to
> >> generate LSPs
> >> more frequently, etc. And instead of cause major disruption for 2
> > days,
> >> the hacker might only need
> >> to cause trouble for 10 minutes on the net (that amount of
> disruption
> >> could be a WSJ frontline story).
> >>
> >> We sure can do lots of things to minimize the impact, but the point
> is
> >> that the security
> >> hole is certainly there.
> >>
> >> thanks.
> >> - Naiming
> >>
> >> On Oct 27, 2011, at 2:43 PM, Mike Shand wrote:
> >>
> >>> Hi Naiming,
> >>>
> >>> I don't understand the assumption of 30 seconds per round. 300mS
> per
> >> round would be slow. Yes, by delaying each round by 30 seconds you 
> >> could spread out the disruption, but the disruption would only last
> > for
> >> a few 100 mS each time around, and would only affect routers
between
> >> (for some value of between) you and the target router, since the
> > target
> >> router would respond with its real LSP as soon as it saw your fake
> > one.
> >>>
> >>> But what you say is correct, in that you can store up a lot of
> LSPs.
> >> if you have 5000 LSPs you have around 2500 opportunities to exert
> some
> >> disruption, each of which will last for a few hundred mS.
> >>>
> >>> Remember that for this to happen the target router has not only to
> >> have died and reset its seq number, but it has to have remained
dead
> >> for at least the maximum lifetime, which in many networks these
days
> > is
> >> set to the maximum of
> >>> 18 hours or so. If it comes back to life before then, the sequence
> >> number will get reset to the current max value of the LSPs still
> > extant
> >> in the network, and the attacker will have no real opportunity to
> use
> >> his stored LSPs.
> >>>
> >>>   Mike
> >>>
> >>> On 27/10/2011 19:48, Naiming Shen wrote:
> >>>> Your example is too modest. as I mentioned in the previous email,
> >> here again:
> >>>>
> >>>> Let's assume the hacker was able to capture all of your LSPs in
> the
> >> past months,
> >>>> and got seq# from #50 to #5000 (in 3 months assume 15 minutes
> each)
> >> on one of
> >>>> your routers. This week the hacker noticed this router had reset
> > the
> >> LSP seq#.
> >>>> The most recent new the router sent out being lsp seq#20.
> >>>>
> >>>> The hacker releases the cached/old LSP seq#50 which has very
> >> different content from
> >>>> your current seq#20's lsp:
> >>>>
> >>>> your router responds to regen seq# 51 (new) hacker then replays 
> >>>> seq# 52 (cached/old) your router responds to regen seq#53 (new) 
> >>>> hacker then replays seq# 54 (cached/old) ....
> >>>>
> >>>> this can go on and on until the hacker runs out its seq#5000.
> > Assume
> >> each round
> >>>> takes 30 seconds, this disruption will last for almost 2 days in
> >> your network,
> >>>> regardless you have authentication or not.
> >>>>
> >>>> - Naiming
> >>>>
> >>>> On Oct 26, 2011, at 10:56 PM, Les Ginsberg (ginsberg) wrote:
> >>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Naiming Shen (naiming)
> >>>>>> Sent: Wednesday, October 26, 2011 10:41 PM
> >>>>>> To: Les Ginsberg (ginsberg)
> >>>>>> Cc: [email-masked]; [email-masked]; 
> >>>>>> [email-masked]; isis mailing list
> >>>>>> Subject: Re: Question regarding draft-chunduri-isis-extended-
> >> sequence-
> >>>>>> no-tlv-00
> >>>>>>
> >>>>>>
> >>>>>> On Oct 26, 2011, at 10:27 PM, Les Ginsberg (ginsberg) wrote:
> >>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Naiming Shen (naiming)
> >>>>>>>> Sent: Wednesday, October 26, 2011 10:21 PM
> >>>>>>>> To: Les Ginsberg (ginsberg)
> >>>>>>>> Cc: [email-masked]; [email-masked]; 
> >>>>>>>> [email-masked]; isis mailing list
> >>>>>>>> Subject: Re: Question regarding draft-chunduri-isis-extended-
> >>>>>> sequence-
> >>>>>>>> no-tlv-00
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Les,
> >>>>>>>>
> >>>>>>>> Even a 'very short disruption' is a disruption I would think.
> >>>>>>>>
> >>>>>>>> But in your example, if I have a way to capture and replay
> your
> >>>>>> seq#X,
> >>>>>>>> then I may
> >>>>>>>> also have a way to capture your seq#X+2, and seq#X+4, etc.
> >>>>>>>> If you were going to update the LSP to seq#X+1, which does
> > cause
> >> a
> >>>>>>>> brief disruption,
> >>>>>>>> then I would release the seq#X+2. and this can go on and on
> and
> >>>>>> cause
> >>>>>>>> a major disruption.
> >>>>>>> In order to cause disruption you have to change the content of
> >> the
> >>>>>> LSP
> >>>>>>> (merely resending an identical LSP does no harm - other than 
> >>>>>>> unnecessarily consuming some CPU time). Once you do that you
> > MUST
> >>>>>> have
> >>>>>>> the key in order to recalculate the correct message digest -
> >>>>>> otherwise
> >>>>>>> the bogus LSP fails authentication. So the problemtic scenario
> > is
> >>>>>>> limited to the transitory (and rare) case I mentioned - it is
> > not
> >> an
> >>>>>>> ongoing disruption.
> >>>>>> But since this is your previous life's LSP, let's say last
> > months,
> >>>>>> there may be
> >>>>>> some changes during the months in operation. and you can also
> re-
> >>>>>> shifting
> >>>>>> your content in different LSPs. so there is no guarantee that
> the
> >> same
> >>>>>> LSP
> >>>>>> last year will have the same content of this year.
> >>>>> So, last week I sent LSP #0 with Seq # 100 and a certain set of
> >> TLVs
> >>>>> (call this OLD-TLVs).
> >>>>> I get shutdown for a week and restarted (cold start) and I send
> > LSP
> >> #0
> >>>>> with Seq #1 with a new set of TLVs (call this NEW-TLVs).
> >>>>>
> >>>>> You as the evil attacker now send LSP #0 Seq #100 OLD-TLVs. As
it
> >> has
> >>>>> valid authentication it is accepted by routers who receive it
and
> >> some
> >>>>> disruption occurs. However once I receive it I recognize it as
> not
> >>>>> matching my local copy and I immediately generate and flood LSP
> #0
> >> Seq
> >>>>> #101 NEW-TLVS. This corrects the problem.
> >>>>>
> >>>>> Now you (evil attacker) have only the following options:
> >>>>>
> >>>>> 1)You can send saved copies of LSP #0 w Seq #<= 100 OLD-TLVS.
> > These
> >>>>> will have valid authentication - but will be discarded by all
> >> routers as
> >>>>> being older than the latest version (Seq #101) that I have
> >> previously
> >>>>> sent.
> >>>>>
> >>>>> 2)You can resend LSP #0 w Seq #101 w content unchanged (NEW-
> TLVs).
> >> Again
> >>>>> this will have valid authentication but as the content is
> > unchanged
> >> it
> >>>>> causes no disruption.
> >>>>>
> >>>>> 3)You can send LSP #0 w Seq #>  101 OLD-TLVs, but since you
don't
> >> have
> >>>>> the key authentication will fail on these LSPs and they will be 
> >>>>> discarded.
> >>>>>
> >>>>> So you get one - and only one - chance to cause disruption - and
> >> this
> >>>>> lasts only briefly and your opportunity only arises in cases
> where
> >> a
> >>>>> router has cold started after being shutdown long enough for the
> >> LSPs
> >>>>> sent by the old incarnation to be aged out from the network.
> >>>>>
> >>>>>  Les
> >>>>>
> >>>>>> - Naiming
> >>>>>>
> >>>>>>> Les
> >>>>>>>
> >>>>>>>> thanks.
> >>>>>>>> - Naiming
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> It is conceivable that if a router had generated an LSP with
> >> seq
> >>>>> #X
> >>>>>>>> and
> >>>>>>>>> then shutdown for a time and then restarted sending LSP w
> >> seq#1,
> >>>>>>> that
> >>>>>>>>> the adversary could replay the LSP w seq #X and it would (in
> >> the
> >>>>>>>> absence
> >>>>>>>>> of a key change) look valid. However this would create only
a
> >> very
> >>>>>>>> short
> >>>>>>>>> disruption - basically the time it took for the restarted
> >> router
> >>>>> to
> >>>>>>>>> generate and flood seq #X+1 - and thereafter attempts by the
> >>>>>>>> adversary
> >>>>>>>>> to generate valid looking newer versions would again fail.
> >>>> _______________________________________________
> >>>> Isis-wg mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/isis-wg
> >>>
> >>> _______________________________________________
> >>> Isis-wg mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/isis-wg
> >>
> >> _______________________________________________
> >> Isis-wg mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 29 Mar 2012 14:24:51 -0700

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

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. 

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 a short disruption
as the base protocol mechanisms mention in #2 above would provide quick
recovery.

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?

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.

Thanx.

   Les

> From: Uma Chunduri [mailto:[email-masked]]
> Sent: Thursday, March 29, 2012 1:51 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
> 
> [CC'ed KARP too]
> 
> In the ISIS wg meeting in Paris, we addressed the concerns raised by
Les and
> Mike in the mailing list.
> As asked by chairs we are summarizing here, the points briefly
discussed
> specifically on the ESN TLV in LSP.
> 
> - Though, the originator updates the sequence number and floods the
same when
> replay is received,
>   the impact of the replayed LSP in the network  *purely* depends on
the
> content of the replayed packet
>   (this could be fewer TLV22s/222s or ..) and also all the nodes in
the
> area/domain could be impacted.
>      - plz note an adversary can potentially do this for any LSP
fragment of
> a particular node/any node.
>      - if a node/card in the network need to be serviced one can't
assume
> always this can be done
>      - In this sense as Naiming indicated if this optional TLV
protection is
> needed or not
Behalf Of
> Les Ginsberg (ginsberg)
> I don't think we have consensus on this yet. I have other concerns
regarding
> SNPs and IIHs which I have not yet raised as I thought it would be
easier to
> discuss one PDU at a time. :-)
> 
> I also think Manav has raised an excellent point and would like to see
his
> question addressed.
> I think this is also debatable. Changes to the protocol come at a cost
- both
> to the protocol vendors and the users of the protocol. I do not share
your
> opinion that all potential security issues have to be addressed. A
prudent
> evaluation of the risks and the costs needs to be made.
> 
>    Les
>

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 29 Mar 2012 20:02:10 -0400

Hi Les,

Plz see my response to your concerns in-line [Uma] 

-- 
Uma C. 

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Thursday, March 29, 2012 2:25 PM
To: Uma Chunduri; Naiming Shen (naiming)
Cc: Mike Shand; [email-masked]; [email-masked]
Subject: RE: [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00

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.

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.

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)

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. 
       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.       

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 29 Mar 2012 17:58:56 -0700

Uma -

> Sent: Thursday, March 29, 2012 5:02 PM
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.
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. 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.

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. 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.

> 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:
months
> or years later
aged
> out of the network - which can be up to 18 hours depending on the
configured
> value for LSP Maxage
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
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
> [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.

   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

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 30 Mar 2012 06:12:32 -0400

Hi Les,

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

and
> myself. It is understood that the difference between one version of a 
> given LSP and another may be small or large
in terms
recognize
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.

having
scenario
handled
only if
aged
> out.

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

attacker
attack to
> a) Attacker stores "many" LSPs without knowing whether a system will
ever
months
aged
configured
> interval between replays Should all of the conditions be met it would 
> still be true that the
replay of
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.

would
earlier,
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.

replay
(depending on
is
are
protocol will
do so
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

usefulness of
another
equally

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 30 Mar 2012 11:04:18 -0700

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

> Sent: Friday, March 30, 2012 3:13 AM
propagated
> until it reaches the originator.
> The originator will recognize that this LSP is "owned" by itself but
looks
> "newer" (based on sequence #)
> 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
> 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
> My point is only that the protocol handles this situation today and it
can be
> easily demonstrated.
> 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.
> 
> >
> attack to have any impact the restarted LSPs must have aged out. I
think we
> agree on that.
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
> 
> >

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 30 Mar 2012 16:32:36 -0400

Hi Les,

For Lsps, the return of investment is worth it or not, lets leave it to the working group and the mainly 
providers of the services to see, and we welcome your  comments on other portion of the doc.
 
-- 
Uma C. 

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Friday, March 30, 2012 11:04 AM
To: Uma Chunduri; Naiming Shen (naiming)
Cc: Mike Shand; [email-masked]; [email-masked]
Subject: RE: [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00

Uma -

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.

  Les

propagated
> [Uma]: ... and all the node who processed and acted on this replay are 
> impacted. You can't precisely quantify, how long and what impact.
> 
looks
> 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
kicked in by
sequence
this you
which
> allow you to recognize the replay and drop has low ROI.
> 
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
> 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 (
Sections
of
can be
to occur
think we
the
to the
you
has low
didn't

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 30 Mar 2012 20:48:09 -0700

Indeed, the deployment issues are another thing that is troubling -
especially in the case of LSPs. I don't think this extension can be
safely enabled for LSPs unless all routers in the network support it.
Consider this simple example:

   R1----R2----R3

R1 does NOT support the extension, but R2 and R3 do support the
extension.

All routers have an LSP originated by R3 - call it R3.00-00 Seq #10 ESSN
# 50

An attacker has an old LSP from a previous incarnation of R3. Call it
R3.00-00 Seq #20 ESSN # 40.
 
The attacker injects this replayed LSP into the network at R1. As the
sequence # is greater than the copy in the local database R1 accepts the
replayed LSP and then floods it to R2. R2 however rejects the replayed
LSP because it has an older ESSN #. LSPDB is now inconsistent between R1
and R2/R3. This condition will persist until R3 generates a new LSP with
sequence # > 20 or until the replayed LSP on R1 ages out.

I think there are similar constraints as regards the use of the
extension in IIHs and SNPs - though in that case it is only necessary to
upgrade all routers on a particular link - and probably support enabling
the extension on a per link basis.

Note that if not all ISs on a LAN segment support the extension, then a
replay attack could result in an inconsistent set of neighbors and
multiple DISs might be elected, rendering the LAN unreliable for
forwarding.

There may be ways to protect against the perils of partial deployment -
which it would be good if the draft addressed - but I do think full
deployment is required for the feature to be enabled.

   Les

> From: Bhatia, Manav (Manav) [mailto:[email-masked]]
> Sent: Friday, March 30, 2012 7:40 PM
> To: Uma Chunduri; Les Ginsberg (ginsberg); Naiming Shen (naiming)
> Subject: RE: [karp] [Isis-wg] Question
regardingdraft-chunduri-isis-extended-
> sequence-no-tlv-00
> 
> Hi Uma,
> 
> > [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
> Well it does introduce an additional burden on the vendors to
implement and
> test this feature. It also places a huge burden on operators to see
the
> impact of deploying this feature. There is no flag day where all
routers are
> upgraded with the new image and you might have to deal with cases
where there
> is a mix of routers that support and don't support this feature. You
will
> have to define some mechanism on how this needs to work. I don't say
its
> unachievable - I am trying to tell you what Les could possibly be
alluding to
> when he mentions "low" ROI.
> 
> Cheers, Manav