Last Call Review of draft-ietf-karp-isis-analysis-04
review-ietf-karp-isis-analysis-04-secdir-lc-takahashi-2015-07-03-00

Let me add one more comment here.
We could probably discourage the use of HMAC-MD5, and encourage the use of
HMAC-SHA family instead.

Take

> -----Original Message-----
> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
> Sent: Friday, July 3, 2015 1:10 PM
> To: 'draft-ietf-karp-isis-analysis.all@tools.ietf.org'
> Cc: 'iesg@ietf.org'; 'secdir@ietf.org'; 'karp-chairs@tools.ietf.org'
> Subject: Secdir review of draft-ietf-karp-isis-analysis-04
>
> Hello,
>
> 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.
>
> This document is ready for publication.
>
> [summary of this document]
>
> This document analyzes the threats of IS-IS protocol.
> It first summarizes the current state of the IS-IS protocol, with special
focus
> on key usage and key management (in section 2), and then analyzes the
security
> gaps in order to identify security requirements (in section 3).
>
> In the summary of the current state of the protocol (section 2), it
already
> mentioned the threats of the protocol, i.e. replay attack and spoofing
attack,
> for each of the three message types of IS-IS protocol.
> Section 3 summarizes, organizes, and develops the threat analysis and
provides
> candidate direction to cope with the threats by listing requirements and
by
> listing related I-D works.
>
> [minor comment]
>
> As mentioned in the security consideration section, this draft does not
modify
> any of the existing protocols.
> It thus does not produce any new security concerns.
> So, the security consideration section seems adequate.
> The authors could consider citing RFC 5310 in Section 5, since I feel like
that
> this draft does not discuss all the content of the consideration section
of
> the rfc (it does discuss major parts of the section, though).
>
> Cheers,
> Take
>