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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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

> -----Original Message-----
> From: Bhatia, Manav (Manav) [mailto:[e-mail]]
> Sent: Friday, March 30, 2012 7:40 PM
> To: Uma Chunduri; Les Ginsberg (ginsberg); Naiming Shen (naiming)
> Cc: Mike Shand; [e-mail]; [e-mail]
> 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
> > quite understand your claim of "low" ROI.
> 
> 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