Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and COMMENT) - resending comment
"Susan Hares" <shares@ndzh.com> Thu, 18 August 2016 02:13 UTC
Return-Path: <shares@ndzh.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D522112D587; Wed, 17 Aug 2016 19:13:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.739
X-Spam-Level: *
X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no 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 LRyVi74PMUgW; Wed, 17 Aug 2016 19:13:00 -0700 (PDT)
Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 A6BED12D1BC; Wed, 17 Aug 2016 19:12:59 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.169.225;
From: Susan Hares <shares@ndzh.com>
To: 'Alia Atlas' <akatlas@gmail.com>, 'Alissa Cooper' <alissa@cooperw.in>
Date: Wed, 17 Aug 2016 22:11:52 -0400
Message-ID: <014a01d1f8f5$e5b27990$b1176cb0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_014B_01D1F8D4.5EA23920"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdH49S7BU0lovAolRGWjp7L/qQslOg==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/mYho7-4bkvIQobGuwY6aaPJOpto>
Cc: 'Jeffrey Haas' <jhaas@pfrc.org>, i2rs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org, 'The IESG' <iesg@ietf.org>, i2rs-chairs@ietf.org
Subject: Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and COMMENT) - resending comment
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2016 02:13:02 -0000
Alia and Alissa: Resending – this comment in case it got ost ------------------------ On the DISCUSS: Operators indicated that there are events which they will want to send publically. One example of such an event is the route establishment/loss (such as the routes available to http://www.routeviews.org/ or looking glass sites). This data is specific route information that is publically known. Right now this information requires a BGP connection, or data from a BGP connection. In the future, it would simply require an I2RS client to have a connection to an I2RS agent. Insecure I2RS Client=======I2RS Agent This data can also be distributed in tiers – where a massive amount of clients connect to an I2RS agent which draws its information in a proxy mode: Insecure Proxy-model secure I2RS client-1========= I2RS Agent /I2RS client ----------------------- I2RS Agent I2RS client-2===========| Does this provide you enough information to resolve your discuss or do you have additional questions? Sue On the editorial From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Wednesday, August 17, 2016 11:07 AM To: Alissa Cooper Cc: The IESG; Jeffrey Haas; i2rs@ietf.org; i2rs-chairs@ietf.org; draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and COMMENT) Hi Alissa, On Wed, Aug 17, 2016 at 10:54 AM, Alissa Cooper <alissa@cooperw.in> wrote: Alissa Cooper has entered the following ballot position for draft-ietf-i2rs-protocol-security-requirements-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- == Section 3.2 == "A non-secure transport can be can be used for publishing telemetry data or other operational state that was specifically indicated to non-confidential in the data model in the Yang syntax." What kind of telemetry data is it that is of no potential interest to any eavesdropper? This is not my area of expertise so I'm having a hard time conceiving of what that could be. I'm also wondering, since I2RS agents and clients will have to support secure transports anyway (and RESTCONF can only be used over a secure transport), why can't they be used for all transfers, instead of allowing this loophole in the name of telemetry, which undoubtedly will end up being used or exploited for other data transfers? If the argument was that this loophole is needed for backwards compatibility with insecure deployments of NETCONF or something like that I think it would make more sense, but my impression from the text is that those will have to be updated anyway to conform to the requirements in this document. Data coming from a router can come from many different line-cards and processors. The line-cards that may be providing the data are not going to be supporting the secure transports anyway. A goal is to allow easy distribution of streaming data and event notifications. As for what type of data, as far as I know, currently IPFIX streams telemetry data without integrity much less authorization protection. There are existing deployments that use gRPC now for streaming telemetry data. Regards, Alia ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In general I agree with Mirja that where other documents already provide definitions, they should be referenced, not copied or summarized, in this document. == Section 2.1 == Using "privacy" as a synonym for "confidentiality" is outmoded, I think, given current understanding of the many other facets of privacy (see, e.g., RFC 6793). I would suggest dropping the definition of data privacy and just using the word confidentiality when that is what you mean. == Section 2.2 == "The I2RS protocol exists as a higher-level protocol which may combine other protocols (NETCONF, RESTCONF, IPFIX and others) within a specific I2RS client-agent relationship with a specific trust for ephemeral configurations, event, tracing, actions, and data flow interactions." Reading the provided definition of "trust," I'm not sure what "with a specific trust for" means in the sentence above. "The I2RS architecture document [I-D.ietf-i2rs-architecture] defines a secondary identity as the entity of some non-I2RS entity (e.g. application) which has requested a particular I2RS client perform an operation." Per my comment above, I would suggest just referencing the definition from the architecture document. The text above is circular ("the entity of some ... entity") and conflates an identity with an identifier. == Section 3.1 == Agree with Mirja that this section is superfluous. == Section 3.3 == Since the normative recommendation here isn't to be enforced by the protocol, why is it SHOULD rather than MUST? Same question applies to SEC-REQ-17. == Section 3.5 == Is the omission of normative language from Sec-REQ-20 purposeful?