[secdir] sectdir review of draft-ietf-isis-node-admin-tag-08
Catherine Meadows <catherine.meadows@nrl.navy.mil> Thu, 21 April 2016 17:37 UTC
Return-Path: <catherine.meadows@nrl.navy.mil>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7EF12E89C; Thu, 21 Apr 2016 10:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level:
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tfop32BSYCFt; Thu, 21 Apr 2016 10:37:00 -0700 (PDT)
Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D2712E887; Thu, 21 Apr 2016 10:36:59 -0700 (PDT)
Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id u3LHatCj020776 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 21 Apr 2016 13:36:56 -0400
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Content-Type: multipart/alternative; boundary="Apple-Mail=_39C57C84-51C0-4DC2-821E-6ACD43419855"
Date: Thu, 21 Apr 2016 13:36:55 -0400
Message-Id: <A72D09E9-4622-41DB-8EA0-62518AA9CA7A@nrl.navy.mil>
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-isis-node-admin-tag.all@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
X-CCS-MailScanner: No viruses found.
X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/drnGXjKp7p94oeVtgWO-GXUUjaM>
Subject: [secdir] sectdir review of draft-ietf-isis-node-admin-tag-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2016 17:37:02 -0000
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: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil <mailto:catherine.meadows@nrl.navy.mil>
- [secdir] sectdir review of draft-ietf-isis-node-a… Catherine Meadows
- Re: [secdir] sectdir review of draft-ietf-isis-no… Hannes Gredler
- Re: [secdir] sectdir review of draft-ietf-isis-no… Catherine Meadows
- Re: [secdir] sectdir review of draft-ietf-isis-no… Pushpasis Sarkar
- Re: [secdir] sectdir review of draft-ietf-isis-no… Pushpasis Sarkar