Last Call Review of draft-ietf-isis-te-metric-extensions-07
review-ietf-isis-te-metric-extensions-07-secdir-lc-weis-2016-01-07-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

I consider this document Ready with nits.

This document adds some “sub-TLVs” to IS-IS Traffic Engineering Extensions
(RFC5305), where the new sub-TLVs describe characteristics for a link (e.g.,
link delay, available bandwidth). It notes in the Abstract and Introduction
that these will be used in real-time networks where performance data is
critical to ensuring timely delivery of information (e.g., stock market data).

The Security Considerations accurately states that it does not introduce
security issues, insomuch that it does not change the behavior of IS-IS or
IS-IS Extensions for Traffic Engineering (RFC 5305). It points to the security
considerations in RFC 5305, which really just points to security considerations
in IS-IS Cryptographic Authentication  (RFC 5304). This is logical, if not so
helpful. Pointing to RFC 5304 directly would be just as useful, in my opinion,
but acceptable the way it is now.

Given that the stated motivation for this document is to pass performance data
across networks where the performance data is considered critical (and the
delay of which has an financial impact), it would be useful for the Security
Considerations to be more specific about risks to the IS-IS TE extensions being
tampered with on the link. For example, it could say that the effect of sending
these IS-iS Traffic Engineering Sub-TLVs over insecure links could result in a
man-in-the-middle attacker delaying real time data to the site, which could
negatively affect the value of the data for that site.

Security Considerations also points to Traffic Engineering Extensions to OSPF
Version 3  (RFC5329) which does not make a lot of sense to me, since OSPF is an
entirely different protocol. I think a better alternate reference might be
IS-IS Security Analysis (RFC7645).

Brian