Re: [secdir] sectdir review of draft-ietf-isis-node-admin-tag-08

[Hannes Gredler <[e-mail]>]

catherine,

i fail to see how this does introduce *new* security concerns.

background:

we have in IS-IS two existing tagging mechanism's:

1) admin-groups for links
    https://tools.ietf.org/html/rfc5305#section-3.1

2) prefix-tags for prefixes
    https://tools.ietf.org/html/rfc5130#section-3.1

both "tagging-spaces" are local administered and have
no global significance.

the purpose of draft-ietf-isis-node-admin-tag-08 is to
add support for a third tagging method which allows tagging
of an entire node using local administered tagging space.
(same operational spirit as in 1) and 2) )

now my question(s):

- why is adding of an local-administered tag with no implied
   semantics considered to be security relevant ?

- what specific (apparently mis-)wording in
   draft-ietf-isis-node-admin-tag makes you think
   it is security relevant ?

/hannes

On 4/21/16 19:36, Catherine Meadows wrote:
> 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.  However,
> 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: [phone]
> fax: [phone]
> email: [e-mail]
> <mailto:[e-mail]>
>