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

From: Uma Chunduri <[email-masked]>
Date: Sun, 1 Apr 2012 09:20:59 -0400

Hi Les,

You raised a good point on partial deployments. Please see my response in-line [Uma]. 

-- 
Uma C. 

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

[Uma]: I am glad you see the problem. As you have been saying this is temporary problem (which is quite true), why do you think 
       this situation would come down to R1 aging out. Are you saying new LSP from originator would never be flooded in this
       LAN segment? I am missing some thing here.

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.

[Uma]: You are so correct here. But, you have to see if no body supports this extension situation is still ugly not only 
       in this LAN segment (of course it's worst here) but in the overall network.

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.
[Uma]: We have few thoughts  on how to avoid being here (and at what cost). We will update the doc with partial deployment section and also 
discuss with you too. Thx.

   Les

> -----Original Message-----
> From: Bhatia, Manav (Manav) [mailto:[email-masked]]
> Sent: Friday, March 30, 2012 7:40 PM
> To: Uma Chunduri; Les Ginsberg (ginsberg); Naiming Shen (naiming)
> Cc: Mike Shand; [email-masked]; [email-masked]
> 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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 1 Apr 2012 09:55:44 -0700

Uma -

> From: Uma Chunduri [mailto:[email-masked]]
> Sent: Sunday, April 01, 2012 6:21 AM
> To: Les Ginsberg (ginsberg); Bhatia, Manav (Manav); Naiming Shen
(naiming)
> sequence-no-tlv-00
> 
> Hi Les,
> 
> You raised a good point on partial deployments. Please see my response
in-
> line [Uma].
> An attacker has an old LSP from a previous incarnation of R3. Call it
R3.00-
> 00 Seq #20 ESSN # 40.
> 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
> [Uma]: I am glad you see the problem. As you have been saying this is
> temporary problem (which is quite true), why do you think
>        this situation would come down to R1 aging out. Are you saying
new LSP
> from originator would never be flooded in this

As the replayed LSP is owned by R3, R3 is the only IS which can generate
a new version. In this example topology, R3 will never see the replayed
LSP because all of its neighbors will reject it without flooding it.
Therefore the legacy systems will continue to use the replayed LSP until
it either ages out or R3 - for other reasons - generates a version with
sequence # >20. Aging could take as long as 18 hours (depending on the
lifetime in the replayed LSP) - and since it is postulated that the
attacker could have stored many old LSPs, when Seq #20 ages out the
attacker could send a replayed LSP with Seq #21 (or greater), so the
duration of this inconsistent state is indeterminate.

While the example topology is simple, it is easy to imagine an
equivalent topology that is more realistic. All that is necessary is for
there to be partial deployment while the owner of the replayed LSP has
neighbors all of which support the extension.

I have assumed in this example that if the replayed LSP actually reached
the originator (R3 in this case) that it would generate a new version
even though the ESSN # indicates the LSP is stale. But it may be that
you intend for the originating system to ignore the replayed LSP in this
case as well (just like R2 does in this case), which would mean it is
even easier to create the pathological state - simply the presence of
one legacy system anywhere in the topology would be sufficient.

   Les

> 
> 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.
> 
> [Uma]: You are so correct here. But, you have to see if no body
supports this
> extension situation is still ugly not only
>        in this LAN segment (of course it's worst here) but in the
overall
> network.
> 
> There may be ways to protect against the perils of partial deployment
- which
> it would be good if the draft addressed -
> [Uma]: We have few thoughts  on how to avoid being here (and at what
cost).
> We will update the doc with partial deployment section and also

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 1 Apr 2012 23:33:24 -0700

In a previous thread we have discussed the use of the proposed extension
in LSPs.

Here are the remainder of my comments on the draft:

In regards to SNPs, the presence of replayed SNPs will cause unnecessary
reflooding of LSPs but will not actually cause any change in the LSPDB
of any router. The unnecessary flooding would be limited to the link on
which the replayed SNPs appear. Because no actual LSPDB changes would
occur as a result of replayed SNPs, this is the one usage which could be
enabled in the presence of partial deployment.

In regards to IIHs, replayed IIHs could cause adjacency flapping which
could be very disruptive. The danger lies when not all systems on a link
support the extension - which on multi-access links can lead to multiple
DISs being elected and violations of the assumption of transitivity. For
this reason, enablement cannot be safely done in the presence of legacy
systems.

Given the discussion in the draft about enhancements to provide routing
protocols with a group key management protocol in the future, it is
prudent to look at the value add of extended sequence #s in the presence
of a group key management protocol. The cost of having router vendors
and their customers implement, deploy, and support extended sequence #s
must be weighed against the benefits.

As discussed in an earlier thread, IS-IS already has a reliable
mechanism to recover from replayed LSPs. I see no significant value in
using this extension in LSPs - and there is significant risk of
introducing prolonged inconsistency in the LSPDB of routers in the
network if any legacy systems exist in the network or are introduced
after the extension has been enabled. The negative consequences of
having a legacy system are significant because, unlike authentication,
extended sequence #s are always optional and the absence of the same do
not prevent adjacency formation and LSP exchange. 

At this point the only significant potential value I see is in IIHs -
and in the presence of a group key management protocol this would be
limited to the period between key rollovers. Once the set of neighbors
on a link is stable, there would be no opportunity to introduce
disruption with replayed IIHs even if the authentication key is not
changed, so the potential value add is limited to periods of instability
without key rollover.

If the draft is to go forward, I would like to see the use in LSPs
removed from the draft and a more complete discussion of the
benefits/consequences of using extended sequence numbers in IIHs/SNPs in
the presence of a group key management protocol. 

   Les

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 5 Apr 2012 15:02:44 -0400

I have a concern about replayed IIHs within TRILL where it is
reasonable to believe that such a change could be universally deployed
or nearly so. I would like to see such a TLV available for at least
that purpose.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Mon, Apr 2, 2012 at 2:33 AM, Les Ginsberg (ginsberg)
<[email-masked]> wrote:
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg