Subject: [Isis-wg] Mirja Kühlewind's No Objection on draft-ietf-isis-remaining-lifetime-03: (with COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Mon, 15 Aug 2016 12:22:03 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-isis-remaining-lifetime-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-remaining-lifetime/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Two small comments:
1) Maybe explain briefly also in this doc what ZeroAgeLifetime is; that
would be helpful!
2) You write:
„Retention of stale LSPs therefore has no negative side effects other
than requiring additional memory for the LSPDB.“
 -> Can this lead to a memory exhaustion attack instead? Should this be
discussed in the security section?

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 15 Aug 2016 19:35:33 +0000

Mirja -

Thanx for your comments.
Inline.

> -----Original Message-----
> From: Mirja Kuehlewind [mailto:[email-masked]]
> Sent: Monday, August 15, 2016 12:22 PM
> To: The IESG
> Cc: [email-masked]; Christian Hopps; isis-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Mirja Kühlewind's No Objection on draft-ietf-isis-remaining-lifetime-
> 03: (with COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> 1) Maybe explain briefly also in this doc what ZeroAgeLifetime is; that would
> be helpful!

[Les:] ISO10589 is the base specification for IS-IS which is explicitly referenced in the draft. It defines ZeroAgeLifetime - as well as many other aspects of LSPs and the operation of the protocol Update Process. I have a strong bias against explaining functionality which is defined by a referenced specification. There are only two possible outcomes:

a)The explanation is 100% consistent with the reference - in which case the text is redundant.
b)The explanation is either not consistent or subject to misinterpretation - in which case we have unnecessarily introduced ambiguity.

So I do not want to add any such explanation.

> 2) You write:
> „Retention of stale LSPs therefore has no negative side effects other than
> requiring additional memory for the LSPDB.“  -> Can this lead to a memory
> exhaustion attack instead? Should this be discussed in the security section?
> 

[Les:] In the existing world LSPs are retained in the database after they are purged. The draft does not change this behavior other than to extend the period during which stale LSPs would be retained by a maximum of 18 hours - and only then in a pathological case.
From an  attack perspective, an attacker cannot introduce new LSPs, they can only cause existing LSPs to be purged prematurely - so we are in fact guaranteeing the expected behavior we should see in the absence of an attack. Therefore I do not see that this introduces a memory exhaustion attack.

   Les