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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Mirja -

Thanx for your comments.
Inline.

> -----Original Message-----
> From: Mirja Kuehlewind [mailto:[e-mail]]
> Sent: Monday, August 15, 2016 12:22 PM
> To: The IESG
> Cc: [e-mail]; Christian Hopps; isis-
> [e-mail]; [e-mail]; [e-mail]
> Subject: Mirja Kühlewind's No Objection on draft-ietf-isis-remaining-lifetime-
> 03: (with COMMENT)
> 
> 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!

[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