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

"Les Ginsberg (ginsberg)" <> Mon, 06 July 2015 21:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 846D61A1B4C for <>; Mon, 6 Jul 2015 14:47:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AeIbQw6VBZVz for <>; Mon, 6 Jul 2015 14:47:46 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 60D021A1B65 for <>; Mon, 6 Jul 2015 14:47:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=27878; q=dns/txt; s=iport; t=1436219263; x=1437428863; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=P5ZmXGNuKgsRouI/QagzjL0RtDHMBIKCeOmjxn5vN6w=; b=JLVoDTqxGbYyiAPQWM9LXeN+ZynV8ms4aR9aiQv2+yxMwVe3E0x/MYnj VqwlE1nQWJhjEn+KBCY0WoVlN74lXyVCkd2t+AXWmRP0U0gf+iTWW1KZp hg1OpmN3jU7wjEpVXslA1AHcDG1coQgwjQv8VuiS7xsHM3NMdR5ymCBLx I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.15,417,1432598400"; d="scan'208,217";a="165927476"
Received: from ([]) by with ESMTP; 06 Jul 2015 21:47:42 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t66Llg6o014075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Jul 2015 21:47:42 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Mon, 6 Jul 2015 16:47:42 -0500
From: "Les Ginsberg (ginsberg)" <>
To: "" <>, "" <>, " list" <>
Thread-Topic: [Isis-wg] draft-decraene-isis-lsp-lifetime-problem-statement-00.txt
Thread-Index: AdC4Ipx32lu/9PxwSImAiodC6BhewAANF+iAAAjUm0A=
Date: Mon, 6 Jul 2015 21:47:41 +0000
Message-ID: <>
References: <770_1436211470_559AD90E_770_16843_1_36185c15-983d-4b98-8b77-109c5a808142@OPEXCLILMA2.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F594897C5xmbalnx02ciscoc_"
MIME-Version: 1.0
Archived-At: <>
Cc: SCHMITZ Christof IMT/OLN <>
Subject: Re: [Isis-wg] draft-decraene-isis-lsp-lifetime-problem-statement-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Jul 2015 21:47:49 -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.


From: Isis-wg [] On Behalf Of
Sent: Monday, July 06, 2015 1:48 PM
To:; list
Subject: Re: [Isis-wg] draft-decraene-isis-lsp-lifetime-problem-statement-00.txt

It has been omitted on purpose of course originally ;-)

format-wise one can  simply reuse something like

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

" list<>" <<>>
"SCHMITZ Christof IMT/OLN" <<>>
Mon, 6 Jul 2015 19:37:44 +0000
[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.

Comments welcomed.

Bruno, Christof

-----Original Message-----
From:<> []
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

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.

Isis-wg mailing list<>