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

[David Lamparter <[e-mail]>]

On Mon, Jul 06, 2015 at 07:37:44PM +0000, [e-mail] wrote:
> 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

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