[secdir] Security review of draft-ietf-isis-extended-sequence-no-tlv-04

"Adam W. Montville" <adam.w.montville@gmail.com> Wed, 01 April 2015 13:29 UTC

Return-Path: <adam.w.montville@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 8D6591A910E; Wed, 1 Apr 2015 06:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 10gAYeloCF2q; Wed, 1 Apr 2015 06:29:03 -0700 (PDT)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E43C1A8ADB; Wed, 1 Apr 2015 06:28:55 -0700 (PDT)
Received: by obvd1 with SMTP id d1so79214419obv.0; Wed, 01 Apr 2015 06:28:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=9ATDWIS43z5RFWiJLu0p8dINyZfe6jRe4gvr6zzJCWo=; b=UyvpfAw5L8ms2dWbh85gnlVUCptWKSsu6pB1uyj6Sj1wiQUjKWT/lqEQ37Exk2o1uk uI2wEaBFv8k7EggfjROgXg+sp3m99uoww/3fCKBFUUQ76PyyjT+hLewU0JODsWKxhfuu +j/1GAAP5s65vCMb0bth1zarIYc5W6TiFoLmpeEYiTpc3+ItUgGQRXAegYbieT+kRscy SBfMzOX+OxcV1qw/spIClSPNglg8EvQ27TbA8XbZ0fEFf49ppkhJ5bHqMr0tni1fgLe2 ofAczLwgK4fCBBQL8a6r6PZOYMZGoHAiTeGQxVc6/2WIMuDuC0lExdUeS3qo7GFmWx2N O2HQ==
X-Received: by with SMTP id q20mr17611959oem.1.1427894926865; Wed, 01 Apr 2015 06:28:46 -0700 (PDT)
Received: from ?IPv6:2602:306:3406:4f00:2d74:e5c1:6b77:ba0e? ([2602:306:3406:4f00:2d74:e5c1:6b77:ba0e]) by mx.google.com with ESMTPSA id x8sm1722414oey.12.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Apr 2015 06:28:45 -0700 (PDT)
From: "Adam W. Montville" <adam.w.montville@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <718D753F-E377-4197-9F01-C34C12EC5CA0@gmail.com>
Date: Wed, 01 Apr 2015 08:28:43 -0500
To: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-isis-extended-sequence-no-tlv.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/-eB6pBtBzd2t85mrH8irRnoyl88>
Subject: [secdir] Security review of draft-ietf-isis-extended-sequence-no-tlv-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2015 13:29:05 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.

This draft is ready with issues.

There are two circumstances within IS-IS that are subject to replay attacks.  One can happen when adjacencies are brought up and an IS sends an IIH (hello).  The other circumstance pertains to replaying CSNP, which may cause replay of PSNP and thus cause LSP flooding.  

This draft proposes a sequence to mitigate replay attacks in both circumstances.  The structure of the sequence is defined as a new TLV called "ESN TLV".  It constists of the three fields, Type, Length, and Value, where Value is to be interpreted as two separate fields.  These two fields are known as Extended Session Sequence Number (ESSN; a 64-bit value, which is non-zero and unsigned), and Packet Sequence Number (PSN; a 32-bit value).  A given ESN is associated with a particular Protocol Data Unit (PDU).  A PDU, therefore, "has" an ESSN, which is associated with a monotonically increasing PSN.  If the PSN wraps or if the device needs to be restarted, then the next ESSN must be larger than the previous ESSN.

This is where I see a potential issue, but maybe I'm missing a limit of practicality.  What happens when the ESSN is at 2^64-1 and needs to increment?  Granted that's a large number, so it might be the case that under no practical circumstance would the ESSN ever become that large; but, if that's the case, then it might be best to state so in the draft.

In the Appendix, the draft also goes into how timestamps may be leveraged (which are potentially more effective at mitigating replay attacks than are sequences), but does not clearly indicate how neighbors would negotiate the use of timestamps or how exactly the timestamps would be used or which format then must be used (a suggestion to look at RFC5905 is made).  

There may be valid operational reasons to favor a sequence over timestamps for replay mitigation, but such considerations appear absent in this draft.  Is there a reason timestamps are being avoided as the replay mitigation solution?


There was at least one area of the text that could probably be clarified for the sake of non-security-familiar folks. The paragraph in section 2.1 could be changed as follows, to make clear that the authenticated case of IIH is where mitigation can be made.

At the time of adjacency bring up an IS sends IIH packet with empty neighbor list (TLV 6) and with or without the authentication information as per provisioned authentication mechanism.  If this packet is replayed later on the broadcast network all ISes in the broadcast network can bounce the adjacency to create a huge churn in the network.

When an adjacency is brought up an IS sends an IIH packet with an empty neighbor list (TLV 6), which can be sent with or without authentication information.  Packets can be replayed later on the broadcast network which may cause all ISes to bounce the adjacency, thus churning the network.  Note that mitigating replay is only possible when authentication information is present.

In general, I recommend reviewing the draft for clarity.

Kind regards,