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

Pushpasis Sarkar <pushpasis.ietf@gmail.com> Sat, 30 April 2016 09:07 UTC

Return-Path: <pushpasis.ietf@gmail.com>
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 E7AD212B051; Sat, 30 Apr 2016 02:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 j9isA0vnb-ZJ; Sat, 30 Apr 2016 02:07:31 -0700 (PDT)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB4B12B05E; Sat, 30 Apr 2016 02:07:31 -0700 (PDT)
Received: by mail-pf0-x22e.google.com with SMTP id 77so25516488pfv.2; Sat, 30 Apr 2016 02:07:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=dWy3D5sRB+ci8lF8hPI2rExOdZ2m0/fxI133ssPLH64=; b=ze4evCuKYkNuIh7exrKJuqsY79q4RMj15wDMQQsnXZMTX2Nxd233UpiQvBlToTPR7j FSxHigWH8PGv7rHr5FGOh+0c6nxsr/UPRc5LoBeW3dCJA05GeB6ztkf19K/fa8bLDo16 LbbD/1/3onOMBF4W1p/+jtqK1AQxJC9vYA/VThZOmc9gOB5o70YzCe8qOk7ytZNeOckl 7ciktEm6xxcazU/dG483kxKQapOvIlFYkIzJOAvGCZEr8zFzqRghJz+mDflVhmYd2Oeg IbUmxe5cKL3Vj7zH03IiPkSegZzWh+dst6lmAtrgF4uaUfEutCIMeN2AQwgTzv3rWTPU u07A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=dWy3D5sRB+ci8lF8hPI2rExOdZ2m0/fxI133ssPLH64=; b=DDM1IMYBfE/v4B7vD2y+kRxBjQnc9awM9pzYZbRk2GWrqWtb+mf1f65CJhgsz1Qmp8 CMgw9HvkHBM0PlVTJTSPnM0QrwQs1o/qKDymrp4xxHxxRqLuVS/J2Jz/NlJa8cEF0Bpv bOVVlthLWQpSNeYTOEg+cfDdWmxdKkcSJkILCHCvmvEuYJjdQahPbphJGRmJQlOdUbp8 OcWaMpMRbFhdYidFW+7uapLE3ihrrVJjez5Necc+ft4+DlY7TWp3+Gam5DTOug19Y7oM 2+v5s9mTiZbYuFSlk6f29S4rzfXpWx3Rci/h/QXrPM21CYbzRLgnQUpomk+DDrJYlIaz TZ9w==
X-Gm-Message-State: AOPr4FVoX96v3y3TAh7GMQb7fPMvREhfhEQbAZnOS6I+XjYjRuGIussHUldcE9BEArFKLA==
X-Received: by 10.98.39.2 with SMTP id n2mr35596660pfn.145.1462007251284; Sat, 30 Apr 2016 02:07:31 -0700 (PDT)
Received: from [192.168.1.235] ([103.6.157.63]) by smtp.gmail.com with ESMTPSA id xn3sm22553369pab.32.2016.04.30.02.07.29 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Apr 2016 02:07:30 -0700 (PDT)
To: Catherine Meadows <catherine.meadows@nrl.navy.mil>, secdir@ietf.org, iesg@ietf.org, draft-ietf-isis-node-admin-tag.all@ietf.org
References: <A72D09E9-4622-41DB-8EA0-62518AA9CA7A@nrl.navy.mil>
From: Pushpasis Sarkar <pushpasis.ietf@gmail.com>
Message-ID: <572475CF.4020905@gmail.com>
Date: Sat, 30 Apr 2016 14:37:27 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <A72D09E9-4622-41DB-8EA0-62518AA9CA7A@nrl.navy.mil>
Content-Type: multipart/alternative; boundary="------------030501000707080706060008"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/y9Ux1I4W5ggw315ns0JSQDW5pWI>
Subject: Re: [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: Sat, 30 Apr 2016 09:07:34 -0000

Hi Catherine,

I have uploaded version -09. Let me know if you have any other comments.

Thanks and Regards,
-Pushpasis

On Thursday 21 April 2016 11:06 PM, 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: 202-767-3490
> fax: 202-404-7942
> email: catherine.meadows@nrl.navy.mil 
> <mailto:catherine.meadows@nrl.navy.mil>
>