Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and COMMENT)

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 18 August 2016 13:48 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.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 193BC12D893; Thu, 18 Aug 2016 06:48:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: 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 cNgy-bzm4frT; Thu, 18 Aug 2016 06:48:01 -0700 (PDT)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 4FF6612D776; Thu, 18 Aug 2016 06:48:01 -0700 (PDT)
Received: by mail-ua0-x22c.google.com with SMTP id n59so28661598uan.2; Thu, 18 Aug 2016 06:48:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=asMH3uBk0TwTMmt5f/RForyDQ4XLKzXoYWglJZ2OFx8=; b=la/yj6WlSRjW77Jxn21xbeJ//mRNjmEeJLUriJnwN64UUJkrhOi4qqavmWn4ljQ7Ut wlpbdJMJuhcTpCgCkTsI2aaP4I5LZ78cp3tuPN7dlmu6rWfWWrTZV3XGfVtEu4zfXXJL gfSw2BgeV40AZJFDY9vbOK7TeLflyNDktTiw1wr47iGUTNVj7ub68ZOhk/4owyVeGezh 9rPXxyyhnqHC//ZxhXMZcmmuzg1edI8hkmoNiDIApa3pqLPFi1McXWo4xwO2a5r4PcHc KjQhefQaxqxlr/GfZMjhfyUI5ARkB+mmK01f08iaUr19xq3vcaQIVFiAd6L5zjP8LO6u zoSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=asMH3uBk0TwTMmt5f/RForyDQ4XLKzXoYWglJZ2OFx8=; b=DIXPON6pcZ3wqfEGyf2OsWrTgAV5idf0sPPQEdxie6zw5CQNq6GT4NYhjcG/UZ5T7o 9j+/j12KDgD86//e0r/vA0U33Sl2AH3T5Vm9a3ml9Kt2SrQSaE1URV9KwDn8+1G9M2wf 9po/1FF0Vk4nV1NT58GKVDjm34BN+0ob+ZMsOJRcquIJRExPoryu9md/mt4CRgB8imff 5cb9PXaFZce4yQgnDhPCoAnWaxl77HOsfhU+oqofwP/eTHpk7mIQRRGIMOjndDz4ncln VdF7Iea8KgqP24OAjXmyq58TChDrqFX2fqSGYdSoN0iU8AHy0qzbOsllDGEb7V71cPxw L9eQ==
X-Gm-Message-State: AEkooutpqt+MoKJbseFAngKbD4OOr6RjhriinlbZBvPwmVVg+VMF0BcbJmP32KgDCdpeAUU8E++eTPzXEHafXw==
X-Received: by 10.31.73.67 with SMTP id w64mr1109262vka.156.1471528080350; Thu, 18 Aug 2016 06:48:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.1.228 with HTTP; Thu, 18 Aug 2016 06:47:59 -0700 (PDT)
In-Reply-To: <xu6csa.oc2ggp.1hge0yu-qmf@mercury.scss.tcd.ie>
References: <147144567895.12152.15403435188950086025.idtracker@ietfa.amsl.com> <CAG4d1rfSYjQLuZYi-g5eOukvMd86FyBs6oyeCk0pdjWYvvLWhA@mail.gmail.com> <5B604C19-7AEF-4C92-B452-A034749A5FCA@cooperw.in> <xu6csa.oc2ggp.1hge0yu-qmf@mercury.scss.tcd.ie>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Thu, 18 Aug 2016 09:47:59 -0400
Message-ID: <CAHbuEH6Bt_PidJ9y+ONodQkjToiqw5Jm_kmEtnjjaGUFRJvtzQ@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/aaWE_HROEVzTX68w33xUFGrQrbA>
Cc: i2rs@ietf.org, Alissa Cooper <alissa@cooperw.in>, i2rs-chairs@ietf.org, Alia Atlas <akatlas@gmail.com>, "iesg@ietf.org" <iesg@ietf.org>, Jeffrey Haas <jhaas@pfrc.org>, draft-ietf-i2rs-protocol-security-requirements@ietf.org
Subject: Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and 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 13:48:03 -0000

On Wed, Aug 17, 2016 at 2:24 PM,  <stephen.farrell@cs.tcd.ie> wrote:
> Hiya,
>
> I'm on vacation so won't be balloting this week and I only had a quick flick of this, but if I'd had time for a proper read I think I'd be asking how realistic are these requirements, possibly as a discuss ballot. If someone wanted to hit defer and blame me (sorry I don't have the right devices with me to do that) that'd be good. But if this draft is  time-critical for the WG then please ignore the above.

I hit the defer button for Stephen.  Alia doesn't want this to sit too
long, so we'll ave to be good about wrapping it up as there are other
groups waiting on it.

Thanks,
Kathleen

>
> S.
>
> On Wed Aug 17 19:02:09 2016 GMT+0200, Alissa Cooper wrote:
>> Hi Alia,
>>
>> > On Aug 17, 2016, at 11:07 AM, Alia Atlas <akatlas@gmail.com> wrote:
>> >
>> > Hi Alissa,
>> >
>> > On Wed, Aug 17, 2016 at 10:54 AM, Alissa Cooper <alissa@cooperw.in <mailto: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 <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/ <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.
>>
>> Will they also not be supporting the I2RS protocol then, given the requirement for support of a secure transport?
>>
>>
>> > 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.
>>
>> What I’m questioning is the choice to extend that model to cases where a third-party controller or application is one endpoint of the data exchange, which is what I thought was part of the motivation for I2RS (happy to be corrected though).
>>
>> >
>> > There are existing deployments that use gRPC now for streaming telemetry data.
>>
>> Ok. So is the implication that the requirements here are needed for backwards compatability with those deployments?
>>
>> Thanks,
>> Alissa
>>
>> >
>> >  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?
>>
>>



-- 

Best regards,
Kathleen