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> >
- [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