Subject: [Isis-wg] draft-decraene-isis-lsp-lifetime-problem-statement-00.txt

From: <[email-masked]>
Date: Mon, 6 Jul 2015 19:37:44 +0000

Hi all,

Please find below a draft describing the problem statement with regards to the possible corruption of the LSP lifetime.
https://tools.ietf.org/html/draft-decraene-isis-lsp-lifetime-problem-statement-00

Comments welcomed.

Thanks,
Regards,
Bruno, Christof

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 06, 2015 9:29 PM

A new version of I-D, draft-decraene-isis-lsp-lifetime-problem-statement-00.txt
has been successfully submitted by Bruno Decraene and posted to the IETF repository.

Name:		draft-decraene-isis-lsp-lifetime-problem-statement
Revision:	00
Title:		IS-IS LSP lifetime corruption - Problem Statement
Document date:	2015-07-06
Group:		Individual Submission
Pages:		6
URL:            https://www.ietf.org/internet-drafts/draft-decraene-isis-lsp-lifetime-problem-statement-00.txt
Status:         https://datatracker.ietf.org/doc/draft-decraene-isis-lsp-lifetime-problem-statement/
Htmlized:       https://tools.ietf.org/html/draft-decraene-isis-lsp-lifetime-problem-statement-00

Abstract:
   The IS-IS protocol exchanges Link State Packet (LSP) to exchange
   routing information.  The lifetime of this LSP is located in the LSP
   header and is neither protected from corruption by the Fletcher
   checksum nor by cryptographic authentication.  So the LSP lifetime
   may be altered, either accidentally or maliciously any time.

   The lifetime field of the LSP is an important field for the correct
   operation of IS-IS.  Corruption of this LSP lifetime may cause
   flooding storm with severe impact in the network.

   This draft documents the problem statement and calls for a solution.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: [email-masked]
Date: Mon, 06 Jul 2015 22:48:13 +0200

It has been omitted on purpose of course originally ;-) 
format-wise one can  simply reuse something
like  https://tools.ietf.org/html/rfc3358

as optional TLV.
The problem is more that it needs to be recomputed when lifetime is
changed (will slow down flooding albeit an incremental computation is
possible if e.g. the algorithm is simple XOR, just XOR current back
and XOR new one on) and it will be hard to deploy incrementally with
that (albeit I can see a simple trick where the last-computing
router-ID is put into the CSUM so if it's off, it means the CSUM is
useless). 
makes sense ? 
--- tony 

----- Ursprüngliche Nachricht -----
Von: [email-masked]
An:"[email-masked] list" 
Cc:"SCHMITZ Christof IMT/OLN" 
Gesendet:Mon, 6 Jul 2015 19:37:44 +0000
Betreff:[Isis-wg]
draft-decraene-isis-lsp-lifetime-problem-statement-00.txt

 Hi all,

 Please find below a draft describing the problem statement with
regards to the possible corruption of the LSP lifetime.
 https://tools.ietf.org/html/draft-decraene-isis-lsp-lifetime-problem-statement-00

 Comments welcomed.

 Thanks,
 Regards,
 Bruno, Christof

 -----Original Message-----
 From: [email-masked] [mailto:[email-masked]] 
 Sent: Monday, July 06, 2015 9:29 PM

 A new version of I-D,
draft-decraene-isis-lsp-lifetime-problem-statement-00.txt
 has been successfully submitted by Bruno Decraene and posted to the
IETF repository.

 Name: draft-decraene-isis-lsp-lifetime-problem-statement
 Revision: 00
 Title: IS-IS LSP lifetime corruption - Problem Statement
 Document date: 2015-07-06
 Group: Individual Submission
 Pages: 6
 URL:
https://www.ietf.org/internet-drafts/draft-decraene-isis-lsp-lifetime-problem-statement-00.txt
 Status:
https://datatracker.ietf.org/doc/draft-decraene-isis-lsp-lifetime-problem-statement/
 Htmlized:
https://tools.ietf.org/html/draft-decraene-isis-lsp-lifetime-problem-statement-00

 Abstract:

 Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
 pas etre diffuses, exploites ou copies sans autorisation. Si vous
avez recu ce message par erreur, veuillez le signaler
 a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,
 Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.

 This message and its attachments may contain confidential or
privileged information that may be protected by law;
 they should not be distributed, used or copied without authorisation.
 If you have received this email in error, please notify the sender
and delete this message and its attachments.
 As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
 Thank you.

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 6 Jul 2015 21:47:41 +0000

Tony –

Sounds like you are proposing that the LSP be modified when it is flooded – whether it be using an optional TLV as in RFC 3358 or some other means. This is a significant change to the Update Process and will have an impact on the existing checksum and crypto hash calculations as well. This in turn will affect how to determine whether LSPDBs are synced.

I think there are safe solutions that don’t have interoperability issues – but I think the first question to be answered is whether WG agrees that this is a problem worth solving.

There are two motivations for solving this:

1)Protection against the odd form of corruption that could occur due to malfunctioning hardware/software

2)Protection against an attacker who could create LSP storms by modifying the Remaining Lifetime of LSPs as they fly by.
(As always in the case of IGPs, an attacker has to be inside the network to accomplish such an attack.)

If you find the problem worthwhile to solve I think we can safely do so.

   Les

From: Isis-wg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 06, 2015 1:48 PM
To: [email-masked]; [email-masked] list
Cc: SCHMITZ Christof IMT/OLN
Subject: Re: [Isis-wg] draft-decraene-isis-lsp-lifetime-problem-statement-00.txt

format-wise one can  simply reuse something like

https://tools.ietf.org/html/rfc3358

as optional TLV.

The problem is more that it needs to be recomputed when lifetime is changed (will slow down flooding albeit an incremental computation is possible if e.g. the algorithm is simple XOR, just XOR current back and XOR new one on) and it will be hard to deploy incrementally with that (albeit I can see a simple trick where the last-computing router-ID is put into the CSUM so if it's off, it means the CSUM is useless).

makes sense ?

--- tony

----- Ursprüngliche Nachricht -----
Von:
[email-masked]<mailto:[email-masked]>

An:
"[email-masked] list<mailto:[email-masked]%20list>" <[email-masked]<mailto:[email-masked]>>
Cc:
"SCHMITZ Christof IMT/OLN" <[email-masked]<mailto:[email-masked]>>
Gesendet:
Mon, 6 Jul 2015 19:37:44 +0000
Betreff:
[Isis-wg] draft-decraene-isis-lsp-lifetime-problem-statement-00.txt

Hi all,

Comments welcomed.

Thanks,
Regards,
Bruno, Christof

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, July 06, 2015 9:29 PM

Abstract:

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

---

From: prz <[email-masked]>
Date: Mon, 06 Jul 2015 14:55:15 -0700

On Mon, 6 Jul 2015 21:47:41 +0000, "Les Ginsberg (ginsberg)" 
 <[email-masked]> wrote:
> Tony –
>
> Sounds like you are proposing that the LSP be modified when it is
> flooded – whether it be using an optional TLV as in RFC 3358 or some
> other means. This is a significant change to the Update Process and
> will have an impact on the existing checksum and crypto hash
> calculations as well. This in turn will affect how to determine
> whether LSPDBs are synced.

 Les, fully agreed, I think I allured in my email that it ain't gonna 
 come cheap. Yepp, it would be a signifcant change.

 agreeing fully with the rest of your email.

 --- tony

>
> I think there are safe solutions that don’t have interoperability
> issues – but I think the first question to be answered is whether WG
> agrees that this is a problem worth solving.
>
> 2)Protection against an attacker who could create LSP storms by
> modifying the Remaining Lifetime of LSPs as they fly by.
>

---

From: <[email-masked]>
Date: Mon, 20 Jul 2015 14:57:12 +0000

Follow up on a comment expressed during the presentation:
 draft-ietf-karp-isis-analysis do _not_  talk about this problem statement.

> From: Isis-wg [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, July 06, 2015 9:38 PM
> To: [email-masked] list
> Subject: [Isis-wg] draft-decraene-isis-lsp-lifetime-problem-statement-00.txt
> 
> Hi all,
> 
> Please find below a draft describing the problem statement with regards to
> the possible corruption of the LSP lifetime.
> ______________________________________________________________
> ___________________________________________________________
> 
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 20 Jul 2015 16:03:34 +0000

To add to what Bruno has said:

In https://tools.ietf.org/id/draft-ietf-karp-isis-analysis-07.txt Section 2.3.2 there is the following paragraph:

A rogue system having access to the common key used to protect
       the LSP, can send an LSP, setting the Remaining Lifetime field to
       zero, and flooding it thereby initiating a purge.  Subsequently,
       this also can cause the sequence number of all the LSPs to
       increase quickly to max out the sequence number space, which can
       cause an IS to shut down for MaxAge + ZeroAgeLifetime period to
       allow the old LSPs to age out in other ISes of the same flooding
       domain.

But this is NOT the issue discussed in Bruno's draft. In particular the problem Bruno discusses does not require the attacker to have the key and the attacker does NOT set RemainingLifetime to 0- it sets it to a small non-zero value. 

These distinctions are important because in Bruno's scenario it is not necessary for the attacker to have the authentication key - yet they can still cause LSPs to be purged prematurely.

    Les

> Sent: Monday, July 20, 2015 7:57 AM
> > Subject: [Isis-wg]
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> > que les pieces jointes. Les messages electroniques etant susceptibles
> > d'alteration, Orange decline toute responsabilite si ce message a ete
> > altere, deforme ou falsifie. Merci.
> >
> > privileged information that may be protected by law; they should not
> > be distributed, used or copied without authorisation.
> __________________________________________________________
> __________________________________________________________
> _____
> 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
> ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
> le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 20 Jul 2015 09:20:52 -0700

Unfortunately yes.

Albeit small, this is a completely open attack vector that can melt a big
network down just nicely.

One can only appeal otherwise to 'security by obscurity' claiming that an
adjacency is necessary first and those are keyed.   However, nothing
prevents an attacker from replaying the flooding it snoops masquerading as
any of the peers while squishing the lifetimes. Or a freakish corruption
may cause the effect (this however would have been noticed long ago IMO
[just like purging on corrupt LSPs was] so I doubt that's a valid argument
within realm of likely occurrences).

So, I would say this problem is in fact a valid problem worth tackling
albeit few people in the world have it ;-) However, those people run some
stuff I wouldn't like to see going down since I cherish a working Internet
;-)

--- tony

On Mon, Jul 20, 2015 at 9:03 AM, Les Ginsberg (ginsberg) <[email-masked]
> wrote:

> But this is NOT the issue discussed in Bruno's draft. In particular the
> problem Bruno discusses does not require the attacker to have the key and
> the attacker does NOT set RemainingLifetime to 0- it sets it to a small
> non-zero value.
>
> These distinctions are important because in Bruno's scenario it is not
> necessary for the attacker to have the authentication key - yet they can
> still cause LSPs to be purged prematurely.
>
>     Les
>
> > Subject: Re: [Isis-wg]
> > ____
> > _
> exploites
> > If you have received this email in error, please notify the sender and
> delete
> > this message and its attachments.

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 20 Jul 2015 16:29:56 +0000

Agree -

1.       It’s different than what’s discussed in the KARP draft

2.       It’s good to solve this issue in a backward compatible way, which can eventually rolled out in all nodes of the network.

--
Uma C.

From: Isis-wg [mailto:[email-masked]] On Behalf Of Tony Przygienda
Sent: Monday, July 20, 2015 9:21 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]; [email-masked] list
Subject: Re: [Isis-wg] draft-decraene-isis-lsp-lifetime-problem-statement-00.txt

Unfortunately yes.

Albeit small, this is a completely open attack vector that can melt a big network down just nicely.

One can only appeal otherwise to 'security by obscurity' claiming that an adjacency is necessary first and those are keyed.   However, nothing prevents an attacker from replaying the flooding it snoops masquerading as any of the peers while squishing the lifetimes. Or a freakish corruption may cause the effect (this however would have been noticed long ago IMO [just like purging on corrupt LSPs was] so I doubt that's a valid argument within realm of likely occurrences).

So, I would say this problem is in fact a valid problem worth tackling albeit few people in the world have it ;-) However, those people run some stuff I wouldn't like to see going down since I cherish a working Internet ;-)

--- tony

On Mon, Jul 20, 2015 at 9:03 AM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
To add to what Bruno has said:

    Les

> From: Isis-wg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> To: [email-masked]<mailto:[email-masked]> list
> > From: Isis-wg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> > To: [email-masked]<mailto:[email-masked]> list
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
> > delete this message and its attachments.

---

From: David Lamparter <[email-masked]>
Date: Tue, 21 Jul 2015 12:30:28 +0200

> https://tools.ietf.org/html/draft-decraene-isis-lsp-lifetime-problem-statement-00

Just wondering - PSNP and CSNP packets have the lifetime and can be
authenticated.  What we want to guard against is LSPDUs on a link that
change the remaining lifetime of an unchanged LSP.  How about this:

- create new capability "restrictive received LSPDU processing" to be
  deployed on a per-circuit level
- under new capability, prohibit processing LSPDUs whose lifetime is not
  either in a small window of the expected value, or 0 / purging
- if the lifetime of a LSP is supposed to actually change, the sending
  system instead sends an (authenticated) PSNP

Unfortunately, this only helps with a narrow attack scenario where there
is an untrusted party on a link that can observe and send modified
packets, but not modify them inflight or drop them.  Similarly, if there
is corruption on the link that affects the first instance of a LSP, this
doesn't help.

Either way - just throwing this out as an idea.  More generically,
keeping LSPDUs as they are, throwing around SNPs (probably with slightly
changed per-circuit flooding semantics) might be part of a solution?
Maybe this mail sparks a thought in someone :)

Cheers,

-David

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 21 Jul 2015 09:54:29 -0700

ok, quite creative approach in itself. I think the 'small window' will
completely defeat any attempt to make that work in generic terms.

We can't predict how quickly really the neighbor floods back when
CSNPs/PSNP'ed @ it's really as well a function of
fn(link speed [possibly shared with other people], #PDUs in neighbor
database, length of your queues to process stuff in ISIS, ...)

so we'd need some kind of formula as to 'what is reasonable'.

Now, there is no way to 'heal' such a problem, will will purge the LSP we
feel has been 'doctored' ? That just makes the problem worse.

Will we just ignore it and rely on retransmission ? That can partition the
network until the LSP truly ages out.

but I didn't think deeper, it's just quick stream-of-consciousness thing
here

--- tony

On Tue, Jul 21, 2015 at 3:30 AM, David Lamparter <[email-masked]> wrote:

> > Please find below a draft describing the problem statement with regards
> to the possible corruption of the LSP lifetime.
> >