Subject: [Isis-wg] Stephen Farrell's No Objection on draft-ietf-isis-te-metric-extensions-09: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 04 Feb 2016 05:48:45 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-isis-te-metric-extensions-09: 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-te-metric-extensions/

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

- Couldn't exposing these metrics (e.g. to a passive
attacker) help the attacker decide which part(s) of a network
to attack or help the attacke to measure the effectiveness of
some other attack they have mounted?  (E.g. a physical attack
on fibre) I think that is worth noting in section 11, perhaps
with guidance that sending this information in clear over
less trusted parts of the network might best be avoided, e.g.
by encrypting that traffic? Put another way... I agree with
Alissa's 2nd discuss point, but I'd argue that the proposed
re-phrasing (from mail from Stefano on Feb 2nd) ought include
the above and not only say "might be sensitive."

- Would it be worth noting that if a future specification
allows some control node or router to ask another to emit
these metrics, then that future specification will need to
consider (abuse of) that control interface as a new attack
vector?

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 8 Feb 2016 16:48:58 +0000

On Feb 4, 2016, at 2:48 PM, Stephen Farrell <[email-masked]> wrote:
> on fibre)

indeed but thus us no different from exposing other link-state information, therefore it falls into the same cryptographic authentication use case mentioned in section 11.

> I think that is worth noting in section 11, perhaps
> these metrics,

clearly not through isis/ospf protocol so it looks a bit out of scope or better: in scope to any api used to instruct/program the router. But in all cases it’s not what’s going to happen in link-state routing.

s.

> then that future specification will need to