Re: [secdir] Secdir review of draft-ietf-teas-yang-te-topo-15

Alvaro Retana <aretana.ietf@gmail.com> Wed, 06 June 2018 11:13 UTC

Return-Path: <aretana.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 2B795130E06; Wed, 6 Jun 2018 04:13:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 P7_o-04ZrZpV; Wed, 6 Jun 2018 04:13:04 -0700 (PDT)
Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (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 5188F1277BB; Wed, 6 Jun 2018 04:13:04 -0700 (PDT)
Received: by mail-ot0-x236.google.com with SMTP id w13-v6so6651028ote.11; Wed, 06 Jun 2018 04:13:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=71hqAvJ784HhDaulk3DhRyE3awcJf59FEq+wmrZnOU8=; b=NJg008N7Szx3bQ/V7DrKnpMZJafyHILqL5Z3NzfF265OI5ki4ec+BjIhA1HQt8t2EP rzbZhVs+TCKSO/mHF8TvUoUfHjbqcyQKv+VUtPn+0hAUHDs9KHZboCFSmR+ecl4CptY3 r0c2tXhUKRmhuhxtsqQ2qiwSz1shsw2tr2TwlS8ECwt6ZIAksIMs0CoW5zs0pn3PwgJW CpL6lTZ3Ypzz1RKX+3ixeBI0g87hRMkE2pQcNOnG4qT05uwhNhrbeBuLtlwelG7ZZGWa 5COqZ0CmmyH6Kn91sV1uWa2SsfInHa2SnlXKDQFVG4XiyLKbMcywuPhJMNCS/yjaF+7p g6tQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=71hqAvJ784HhDaulk3DhRyE3awcJf59FEq+wmrZnOU8=; b=QFGPYcuRZPHA3BJfEGcI9p8+PuDATBDVJ4KFm9nGN12AM92zDPk8wk8tUC1bxQRFg4 6ZoZ/D6BzUhi7KCQt0xbaTEiA2GCmjGFUJBabCcbfjIyc7HNQfYCk6yoQ/3cL/c4yyAM pv5nJQZT6e+KhoPvs81g0975xqQ4SYGMW3TZq5v2vvYqeegqk1duepV7HmFndqfhdUSG udsMwW8ELVpCQn86DEpwuUbzmsK/Txhkwj7Z/dJKZh5J0iY7N5OJqXyoxFG3zxbURyn3 1PiK3MDzus9I6H3pXT4a0gsdc5NmaeHdzJJXjqH80WYJRmY0alovuSWn2pGaRzI3ywGU JnbQ==
X-Gm-Message-State: APt69E2BhQXvtglD7UbWJo0nBgCPU10umpKBfb6Kwh65Dw8i+Aws6k9M +ZIfLXq06OBeTbENmNY4J4mxNNavovSZutoFLdI=
X-Google-Smtp-Source: ADUXVKKMkT+VBQ85adhkyi9qqbFmwmhJdQvDBp/cLTstKsfPVP6g8Ahs6KIV8Am7o4602HxP7ESE1gYfc7rqNqptomA=
X-Received: by 2002:aca:f141:: with SMTP id p62-v6mr1484296oih.80.1528283583703; Wed, 06 Jun 2018 04:13:03 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 6 Jun 2018 07:13:02 -0400
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <c50db559-a144-29d2-c486-626cfe1d372f@labn.net>
References: <1b9239b4-ff6a-4f85-4c6e-8b714cf6b6a3@gmail.com> <c50db559-a144-29d2-c486-626cfe1d372f@labn.net>
X-Mailer: Airmail (467)
MIME-Version: 1.0
Date: Wed, 06 Jun 2018 07:13:02 -0400
Message-ID: <CAMMESszuwyNK302J9LP-SZ4ViQEmV1k5cDNjRSd7r22ie9YeFw@mail.gmail.com>
To: Lou Berger <lberger@labn.net>, draft-ietf-teas-yang-te-topo.all@ietf.org
Cc: secdir@ietf.org, Melinda Shore <melinda.shore@gmail.com>, IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001f6f8f056df7408f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/uPi7CF9kDUQvcky211DhXRggcIQ>
Subject: Re: [secdir] Secdir review of draft-ietf-teas-yang-te-topo-15
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.26
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: Wed, 06 Jun 2018 11:13:09 -0000

Hi!

The updated section looks a lot better to me.  However, I think it is
important to call out the fact that the sensitive information in the
readable data nodes includes geolocation.

Alvaro.

On June 5, 2018 at 10:23:18 AM, Lou Berger (lberger@labn.net) wrote:

Melinda,

    The authors have published an update with a revised security
considerations section, please take a look at your convenience and let
the authors know if you see that more is needed.

https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-16#section-8

Lou
(Doc Shepherd)
On 5/31/2018 11:19 PM, Melinda Shore 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.
>
> The summary of the review is Ready with issues
>
> This document defines a technology-agnostic YANG data model for
> representation of traffic engineering topologies, and is intended to
> serve as a base model for other technology-specific traffic engineering
> topology models.
>
> The document is clearly written and appears comprehensive with respect
> to its subject matter. I suspect that sections 1-4 would be a useful
> reference for people wanting to learn about TE topologies in general,
> and I enjoyed reading it.
>
> The security considerations section is scanty and, unfortunately,
> insufficient. The statement "The data-model by itself does not create
> any security implications" seems questionable at best, since it contains
> information about network topology and the treatment of traffic,
> which may be of value to an attacker. The lack of discussion of
> the threat environment is particularly problematic given that the
> model is intended to be used for manipulating TE topologies. The
> authors may want to look to draft-ietf-i2rs-yang-network-topo as
> a model (no pun intended) of a good security considerations
> section for a topology model. I don't see how this document can
> be published with the security considerations section in its current
> condition.
>
> This is really a trivial nit, but a nit nevertheless - the second
> paragraph of the terminology section probably belongs in the
> introduction instead, as it lays out expectations for the reader
> and contains a pointer to introductory material for readers
> unfamiliar with the IETF's traffic engineering work.
>
> Melinda
>