Skip to main content

Last Call Review of draft-ietf-isis-node-admin-tag-08

Request Review of draft-ietf-isis-node-admin-tag
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-04-29
Requested 2016-04-21
Authors Pushpasis Sarkar , Hannes Gredler , Shraddha Hegde , Stephane Litkowski , Bruno Decraene
I-D last updated 2016-04-28
Completed reviews Genart Last Call review of -08 by Peter E. Yee (diff)
Genart Last Call review of -08 by Peter E. Yee (diff)
Secdir Last Call review of -08 by Catherine Meadows (diff)
Opsdir Last Call review of -08 by Jürgen Schönwälder (diff)
Rtgdir Early review of -08 by Andrew G. Malis (diff)
Assignment Reviewer Catherine Meadows
State Completed
Review review-ietf-isis-node-admin-tag-08-secdir-lc-meadows-2016-04-28
Reviewed revision 08 (document currently at 11)
Result Has Issues
Completed 2016-04-28
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 draft describes an extension to the IS-IS routing protocol, that allows
tagging and grouping of nodes

in an IS-IS domain.  This makes it possible to increase the efficiency of route
and path selection, since the tags

give information about a router’s capabilities.

The Security Considerations section correctly identifies one of the main
security risks of using such tags:  they may leak

sensitive information about, e.g., geographical location.   However, I’m
confused by the statement following that:

“This document does not introduce any new security concerns.  Security concerns
for IS-IS are already addressed in

[ISO10589], [RFC5304], and [RFC5310] are are applicable to the mechanisms
described in this document.”

As far as I can tell, this document *does* introduce new security concerns,
because the tags may reveal sensitive

information that may not have been made available otherwise.  Moreover, RFCs
5304 and 5310 concern authentication, not

secrecy, and so do not address information leakage at all.  My own suggestion

for a recommendation would be that implementors should weigh the benefits of
putting certain kinds of information on tags

versus the risk of its being used by an attacker, and make their decisions
accordingly.  This would not be a SHOULD a MUST

recommendation by the way, but simply advisory.

I’m not sure what is meant by the last sentence in this paragraph:

 Extended authentication mechanisms described in [RFC5304] or [RFC5310] SHOULD
 be used in

   deployments where attackers have access to the physical networks and

   nodes included in the IS-IS domain are vulnerable.

Is this addressing the problem of sensitive information on tags?  If so, you
need to say how.   If it is addressing

spoofing of tags, it should be given its own paragraph, and the threat you are
talking about should be made clear.

In the last paragraph, on the misattribution of tags from different domains,
what would you recommend for mitigating against

this problem?  Also, since this is in the security considerations section, you
should say something about how an attacker

could take advantage of it.

In my opinion, the Security Considerations section needs a major revision.

I consider this document Almost Ready, because the purpose of the revision
would be mainly to make the section more clear, not to address

any overlooked security problems.

Catherine Meadows

Naval Research Laboratory

Code 5543

4555 Overlook Ave., S.W.

Washington DC, 20375

phone: 202-767-3490

fax: 202-404-7942


catherine.meadows at