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

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 <equinox@diac24.net> wrote:

> On Mon, Jul 06, 2015 at 07:37:44PM +0000, bruno.decraene@orange.com 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
>
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
>