Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Kathleen Moriarty <> Mon, 22 August 2016 19:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E2CC12D7D1; Mon, 22 Aug 2016 12:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jGSGl3orwwt7; Mon, 22 Aug 2016 12:51:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B8E1312D177; Mon, 22 Aug 2016 12:51:12 -0700 (PDT)
Received: by with SMTP id 74so208510214uau.0; Mon, 22 Aug 2016 12:51:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+5ZA9oxKqs186BrgNj5xJoJKtl/PlN4atOH2yXtLraU=; b=NnP+Y4jGutBiStTGU+N0owO7FaPR1l7NrVcPUKVjlSyoqClm6nfsYHirmqIkSqhamy zcd88l5gE9YunMS72PFVvSklmvcuCPGgADXE3MCDlzWE/+ocQ9fsFI361OfVwOZohXRq Fn7nnYXnzQ/q3kcfucIZLntalmZ4xQELRtnfvP0fpoPwVEUcOAOMouvB1FtHlVqhgzm+ Jysm2meshKk1Gf0iFHAsR5yRlRBLMj79gC7frkodfpg0XHUuqVxCyerBexhNq0MKCLqV z17voydHlJi6tQm4NN69cAQjbHIJg67HZC+MJKOIMKJETD4FqY0ujHdTaeT9OtoRtmY6 RRuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+5ZA9oxKqs186BrgNj5xJoJKtl/PlN4atOH2yXtLraU=; b=UtelagDvMOCAf+LF9gELHLm9oKxHUQyNwusHftRMl9DQjidDhzdY47NDBJtQypepTf oX3n26kw26n4z44HzuD1F3Qdcb0W7rWOpOvzgP7M0MC05acTdCDvC+EcDGDGvHrLJWL7 9tHFmb8F9RQhuMzfqdQgBLEdNHHCoN0fX0wWqIKOIXKPGdvjwOjFHZVk8VtBGBnw+4kD CEEbFDQTgdJaa0mlErznB8e2U/UF0mj+D8TiZx5MraPU5qhHTTeNHER8pwQzkd/NnYZP vD0OdiTpcjvRxCryjbqbpMPFy0sgqZjcjW4d8kt9cnFHkfyFrruWmuW/iEisBxFJa8dR Bngw==
X-Gm-Message-State: AEkoouucP7FGzXM8blus+3WyyFnKF9/zQVEByT1oyTrmzGwS/RGzPRPJl2DCsAHIK6nb1R/VPL5rdtPBB5w/jw==
X-Received: by with SMTP id 61mr9604463uak.99.1471895471702; Mon, 22 Aug 2016 12:51:11 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 22 Aug 2016 12:51:09 -0700 (PDT)
In-Reply-To: <>
References: <051701d1f952$c4ae0b30$4e0a2190$> <> <> <003801d1f97f$3d16eb10$b744c130$> <20160819085756.GA6759@elstar.local> <01e501d1fa07$6d613fe0$4823bfa0$> <> <027a01d1fa12$3879b270$a96d1750$> <> <> <>
From: Kathleen Moriarty <>
Date: Mon, 22 Aug 2016 15:51:09 -0400
Message-ID: <>
To: Jeffrey Haas <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
X-Mailman-Approved-At: Tue, 23 Aug 2016 07:35:38 -0700
Cc: "" <>, Juergen Schoenwaelder <>, Alissa Cooper <>, Andy Bierman <>,, IESG <>, Joel Halpern <>, Lou Berger <>, Susan Hares <>,
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Aug 2016 19:51:14 -0000

On Mon, Aug 22, 2016 at 3:45 PM, Jeffrey Haas <> wrote:
> I'm lagging in my email, as usual.  However, this one caught my eye:
> On Fri, Aug 19, 2016 at 07:23:47AM -0700, Andy Bierman wrote:
>> We could have been tagging MIB objects all along, but we don't.
>> Imagine if there was a debate for every single OBJECT-TYPE macro
>> "is this leaf OK for noAuth/noPriv?"
>> Are there even clear SEC-DIR guidelines on how one would decide this
>> debate in a WG? Does SEC-DIR really want to be flooded with review
>> requests so they become a bottleneck in YANG RFC publication process?
> I wanted to point out some of the per-object security evaluation that is
> already imposed on MIB modules.  Consider the following text from RFC 4273:
> :    There are a number of managed objects in this MIB that contain
> :    sensitive information regarding the operation of a network.  For
> :    example, a BGP peer's local and remote addresses might be sensitive
> :    for ISPs who want to keep interface addresses on routers confidential
> :    in order to prevent router addresses used for a denial of service
> :    attack or spoofing.
> :
> :    Therefore, it is important in most environments to control read
> :    access to these objects and possibly to even encrypt the values of
> :    these object when sending them over the network via SNMP.
> In some respect, the discussion with regard to I2RS annotation of yang nodes
> with security considerations have precedence.  It could be done in the
> containing documents' security considerations section.  It could be part of
> the description clause for the node.
> Having some notion of the consideration available as a machine-parseable
> markup thus doesn't seem completely unreasonable.
> The essence of your point, Andy, and I believe Juergen's is given a presmise
> of "secure by default", is it okay to mark things as "the author of this
> module believes this to be okay to be insecure by default"?
> Possibly not.  As you both mention, it will depend on the circumstances of a
> given operator's deployment.
> The underlying I2RS question is how to mark nodes in such a way that the
> insecure transport protocols may be permitted to publish them without
> requiring every single node to be audited if you have relatively weak
> deployment considerations?  If the answer is "read the security
> considerations and write a filter", it's not the answer i2rs is looking for.

I think it's just that it is easier to mark the items that require
confidentiality and integrity protection, when that is clear, rather
than trying to figure out that something is absolutely not in need of
any confidentiality and integrity protections.  In this case, you are
not saying that items don't need security, you are just not taking an
official stance and it's up to the user to turn on or off the default
knob for session transport security.

> -- Jeff


Best regards,