headers
Les Ginsberg (ginsberg | 31 Mar 2012 05:48
Picon
Favicon

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

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
(Continue reading)

Permalink | Reply |
headers
Uma Chunduri | 1 Apr 2012 15:20
Picon
Favicon

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

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
(Continue reading)

Permalink | Reply |
headers
Les Ginsberg (ginsberg | 1 Apr 2012 18:55
Picon
Favicon

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

Uma -

> -----Original Message-----
> From: Uma Chunduri [mailto:uma.chunduri <at> ericsson.com]
> Sent: Sunday, April 01, 2012 6:21 AM
> To: Les Ginsberg (ginsberg); Bhatia, Manav (Manav); Naiming Shen
(naiming)
> Cc: Mike Shand; isis-wg <at> ietf.org; karp <at> ietf.org
> Subject: RE: [karp] [Isis-wg] Question
regardingdraft-chunduri-isis-extended-
> sequence-no-tlv-00
> 
> 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
(Continue reading)

Permalink | Reply |
headers
Les Ginsberg (ginsberg | 2 Apr 2012 08:33
Picon
Favicon

draft-chunduri-isis-extended-sequence-no-tlv - other comments

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
(Continue reading)

Permalink | Reply |
headers
Donald Eastlake | 5 Apr 2012 21:02
Picon

Re: draft-chunduri-isis-extended-sequence-no-tlv - other comments

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
 d3e3e3 <at> gmail.com

On Mon, Apr 2, 2012 at 2:33 AM, Les Ginsberg (ginsberg)
<ginsberg <at> cisco.com> wrote:
> 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
(Continue reading)

Permalink | Reply |
headers
Uma Chunduri | 10 Oct 2012 01:35
Picon
Favicon

Re: draft-chunduri-isis-extended-sequence-no-tlv - other comments

Les,
 
Replies in-line [Uma]:
 
 
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.

[Uma]:  draft-chunduri-isis-extended-sequence-no-tlv-02.txt has been updated (section 5) to cover the partial deployment cases. This addressees not only IIH but all PDUs. There is no flag day requirement here.

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.

[Uma]: You talked about the cost above. When an operator deploys any  key management protocol in general, the advantages it brings in are far more bigger than the mitigation of  replay attacks.  But, the cost could be prohibitive if any key management protocol including group key management is deployed only  for the purpose of replay protection. Just for this reason a manual key mechanism to effectively eliminate the issue with replay attack is always useful. This is clearly discussed in Section 1 of the document. It's also worth mentioning here,  neither such a group keying RFC which can derive keys for a group IGPs look for  exist yet nor a smooth mechanism for integration yet defined.

As discussed in an earlier thread, IS-IS already has a reliable mechanism to recover from replayed LSPs.

[Uma]: We discussed in length on this and reliable recovery comes only after the replay is successful and the certain damage it brings in all over.


We take this opportunity acknowledge for providing early feedback on the solution for partial deployment issue.

--

Uma C.

 

 

 

_______________________________________________
Isis-wg mailing list
Isis-wg <at> ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
Permalink | Reply |
headers
Les Ginsberg (ginsberg | 11 Oct 2012 06:16
Picon
Favicon

Re: draft-chunduri-isis-extended-sequence-no-tlv - other comments

Uma –

 

In regards to the new Section 5 on deployment considerations, I think your presentation is a bit misleading. It suggests that if you follow the steps outlined (enable send only, then enable verify) that you are guaranteed a hitless transition. But this is only the case if there is no replay attack occurring during the transition. I think you need to emphasize that for the appropriate scope (link for IIHs, SNPs – area/domain for LSPs) that the transition to “verify” needs to be made as close to atomically as possible so as to avoid inconsistencies which can occur if a replay attack occurs during the transition window.

 

In regards to the usefulness of the extension in LSPs I think your presentation is less than candid. You say in Section 2 that LSPs are vulnerable to inter-session replay attack – but, as we have previously discussed at length, the inter-session LSP replay attack scenarios are highly unlikely and the same base protocol mechanisms which protect LSPs against intra-session replays also allow the protocol to quickly recover from inter-session attacks. This differs markedly from the case for IIHs and SNPs where no replay protection is available at present.

 

The value add of Extended Sequence # in LSPs is about as close to nil as one can get. I would much prefer if the use of Extended Sequence #s in LSPs was removed from the draft (with explanation as to why). If you are unwilling to do that at least be fair in your presentation. You have a good use case argument for IIHs and SNPs – but the case for LSPs is quite weak and it would be good to be candid about that so vendors/customers can understand the value proposition .

 

   Les

 

 

From: Uma Chunduri [mailto:uma.chunduri <at> ericsson.com]
Sent: Tuesday, October 09, 2012 4:36 PM
To: Les Ginsberg (ginsberg); Bhatia, Manav (Manav); Naiming Shen (naiming)
Cc: Mike Shand; isis-wg <at> ietf.org; karp <at> ietf.org
Subject: RE: draft-chunduri-isis-extended-sequence-no-tlv - other comments

 

Les,

 

Replies in-line [Uma]:

 

 

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.

[Uma]:  draft-chunduri-isis-extended-sequence-no-tlv-02.txt has been updated (section 5) to cover the partial deployment cases. This addressees not only IIH but all PDUs. There is no flag day requirement here.

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.

[Uma]: You talked about the cost above. When an operator deploys any  key management protocol in general, the advantages it brings in are far more bigger than the mitigation of  replay attacks.  But, the cost could be prohibitive if any key management protocol including group key management is deployed only  for the purpose of replay protection. Just for this reason a manual key mechanism to effectively eliminate the issue with replay attack is always useful. This is clearly discussed in Section 1 of the document. It's also worth mentioning here,  neither such a group keying RFC which can derive keys for a group IGPs look for  exist yet nor a smooth mechanism for integration yet defined.

As discussed in an earlier thread, IS-IS already has a reliable mechanism to recover from replayed LSPs.

[Uma]: We discussed in length on this and reliable recovery comes only after the replay is successful and the certain damage it brings in all over.


We take this opportunity acknowledge for providing early feedback on the solution for partial deployment issue.

--

Uma C.

 

 

 

_______________________________________________
Isis-wg mailing list
Isis-wg <at> ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
Permalink | Reply |
headers
Uma Chunduri | 15 Dec 2012 02:30
Picon
Favicon

Re: draft-chunduri-isis-extended-sequence-no-tlv - other comments

Les,

 

          >>>>>> I would much prefer if the use of Extended Sequence #s in LSPs was removed from the draft (with explanation as to why).  

         >>>>>> If you are unwilling to do that at least be fair in your presentation.  

 

As discussed further in Atlanta with you and other folks, we would remove the ESN coverage to LSPs with explanation on why ( problem is clearly document in the gap analysis document).

 

           >>>>>>> You have a good use case argument for IIHs and SNPs –  

Thx

 

--

Uma C.

 

  

_______________________________________________
Isis-wg mailing list
Isis-wg <at> ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
Permalink | Reply |
headers
Manav Bhatia | 31 Mar 2012 04:41
Picon
Favicon
Gravatar

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

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

Cheers, Manav

> -----Original Message-----
> From: karp-bounces <at> ietf.org [mailto:karp-bounces <at> ietf.org] On Behalf 
> Of Les Ginsberg (ginsberg)
> Sent: Friday, March 30, 2012 11:34 PM
> To: Uma Chunduri; Naiming Shen (naiming)
> Cc: Mike Shand; isis-wg <at> ietf.org; karp <at> ietf.org
> 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:uma.chunduri <at> ericsson.com]
> > Sent: Friday, March 30, 2012 3:13 AM
> > To: Les Ginsberg (ginsberg); Naiming Shen (naiming)
> > Cc: Mike Shand; isis-wg <at> ietf.org; karp <at> ietf.org
> > 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
> karp <at> ietf.org
> https://www.ietf.org/mailman/listinfo/karp
> 
_______________________________________________
karp mailing list
karp <at> ietf.org
https://www.ietf.org/mailman/listinfo/karp

_______________________________________________
Isis-wg mailing list
Isis-wg <at> ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
Permalink | Reply |

Gmane