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

["Stefano Previdi (sprevidi)" <[e-mail]>]

On Feb 4, 2016, at 2:48 PM, Stephen Farrell <[e-mail]> wrote:
> 
> 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)


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
> 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,


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
> consider (abuse of) that control interface as a new attack
> vector?
> 
>