Subject: [Isis-wg] Data Confidentiality in ISIS draft-aravind-isis-confidentiality-data-00

From: <[email-masked]>
Date: Wed, 12 Nov 2014 19:48:06 +0530

Hi All,

Proposed a mechanism to improve the data confidentiality in ISIS. Kindly let me know your valuable comments.

Name:                  draft-aravind-isis-confidentiality-data

Revision:              00

Title:                      Data Confidentiality in IS-IS

Document date:               2014-11-12

Group:                  Individual Submission

Pages:                   5

URL:            http://www.ietf.org/internet-drafts/draft-aravind-isis-confidentiality-data-00.txt

Status:         https://datatracker.ietf.org/doc/draft-aravind-isis-confidentiality-data/

Htmlized:       http://tools.ietf.org/html/draft-aravind-isis-confidentiality-data-00

Abstract:

   This document specifies the mechanism to provide data confidentiality

   for Intermediate System to Intermediate System (IS-IS) Link State

   PDUs (LSPs) and avoid possible replay attacks.

Thanks,
S. Aravind Prasad

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 21 Nov 2014 19:46:25 +0000

Aravind -

You seem to be unfamiliar with some aspects of the IS-IS Update Process as well as how authentication is supported.

When an LSP is received by a system what it does with the received LSP depends upon whether the LSP is determined to be newer, the same as, or older than the version currently in the local LSPDB.

The determination is based on:

a)Sequence number - higher sequence numbers are newer
b)Remaining Lifetime - zero remaining lifetime is considered newer than non-zero remaining lifetime

There is no comparison done between two non-zero lifetimes I.e. if I receive an LSP w Remaining Lifetime 100 and I currently have a copy of the same LSP (i.e. same LSPID and same sequence number) with remaining lifetime 200 I do NOT update the remaining lifetime field in my LSPDB. The two LSPs are treated as the same. Other than acknowledging receipt of the LSP (on Pt-PT circuit) no action is taken.

Therefore it is not accurate to state that because RemainingLifetime is NOT part of the authentication computation it is possible to cause LSPs to age out prematurely by "replaying " them w a different RemainingLifetime.

In regards to purges, when purging an LSP all TLV content in the LSP must be removed except for:

Authentication TLV
Purge Originator TLV

This then requires that the purge initiator recalculate authentication - replaying an LSP that has non-zero remaining lifetime by simply changing the remaining lifetime field to 0 will result in an LSP which is discarded by receivers.

In short, the problems you mention in your draft do not exist.

A closer reading of the following is recommended:

ISP 10589 Section 7.3.16
RFC 5304
RFC 6232

   Les

From: Isis-wg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, November 12, 2014 6:18 AM
To: [email-masked]
Subject: [Isis-wg] Data Confidentiality in ISIS draft-aravind-isis-confidentiality-data-00

Hi All,

Revision:              00

Pages:                   5

Abstract:

Thanks,
S. Aravind Prasad

---

From: <[email-masked]>
Date: Mon, 24 Nov 2014 18:54:05 +0530

Hi Les,

Thanks for the comments.

According to RFC 6039 section 4.2:

"The Remaining Lifetime field in the LSP is not covered by the authentication.  An IS-IS router can receive its own self-generated LSP segment with zero lifetime remaining.  In that case, if it has a copy with non-zero lifetime, it purges that LSP, i.e., it increments the current sequence number and floods all the segments again.  This is much worse in IS-IS than in OSPF because there is only one LSP other than the pseudonode LSPs for the LANs on which the IS-IS router is the Designated Intermediate System (DIS).
In this way, an attacker can force the router to flood all segments  -- potentially a large number if the number of routes is large.  It also causes the sequence number of all the LSPs to increase fast.  If the sequence number increases to the maximum (0xFFFFFFFF), the IS-IS process must shut down for around 20 minutes (the product of MaxAge + ZeroAgeLifetime) to allow the old LSPs to age out of all the router databases."

Hence, I think the problem still exists in ISIS. Kindly let me know your comments.

Thanks,
S. Aravind Prasad

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Saturday, November 22, 2014 1:16 AM
To: Sridharan, Aravind; [email-masked]
Subject: RE: [Isis-wg] Data Confidentiality in ISIS draft-aravind-isis-confidentiality-data-00

Aravind -

Authentication TLV
Purge Originator TLV

ISP 10589 Section 7.3.16
RFC 5304
RFC 6232

   Les

From: Isis-wg [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, November 12, 2014 6:18 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Isis-wg] Data Confidentiality in ISIS draft-aravind-isis-confidentiality-data-00

Hi All,

Revision:              00

Pages:                   5

Abstract:

Thanks,
S. Aravind Prasad

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 24 Nov 2014 16:04:36 +0000

Aravind -

This was thoroughly discussed in the context of draft-chunduri-isis-extended-sequence-no-tlv. I suggest you go back through the WG email archives and reread the discussion. Here is one link to get you started

http://www.ietf.org/mail-archive/web/isis-wg/current/msg02986.html

The conclusion of the thread was that current protocol  recovery mechanisms are more than adequate - which is why extended sequence # was not applied to LSPs.

   Les

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 24, 2014 5:24 AM
To: Les Ginsberg (ginsberg); [email-masked]
Subject: RE: [Isis-wg] Data Confidentiality in ISIS draft-aravind-isis-confidentiality-data-00

Hi Les,

Thanks for the comments.

Thanks,
S. Aravind Prasad

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Saturday, November 22, 2014 1:16 AM
To: Sridharan, Aravind; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] Data Confidentiality in ISIS draft-aravind-isis-confidentiality-data-00

Aravind -

Authentication TLV
Purge Originator TLV

ISP 10589 Section 7.3.16
RFC 5304
RFC 6232

   Les

Hi All,

Revision:              00

Pages:                   5

Abstract:

Thanks,
S. Aravind Prasad