Re: [Netconf] LC on subscribed-notifications-10

"Eric Voit (evoit)" <evoit@cisco.com> Wed, 14 March 2018 17:14 UTC

Return-Path: <evoit@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2355120724; Wed, 14 Mar 2018 10:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.631
X-Spam-Level:
X-Spam-Status: No, score=-12.631 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 763rvrwNdnrp; Wed, 14 Mar 2018 10:14:54 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA277120227; Wed, 14 Mar 2018 10:14:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5354; q=dns/txt; s=iport; t=1521047693; x=1522257293; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=n8AbDbq88FJrLFAHrvdn1DNJ8g9Vzz1bCyspuLnwPBU=; b=AqtSnCA/ZGcZ0MQH6IGZhwD30GIRNKi1GEDNFiVRMzAFKv8Xp2R8Ybzl qAKyXkQXYEZjyVZMYT9pGivdR9hqghIscuhR+95H0/6OVhRfh+xaPO3cD yUKyfgysQtU+VBJSzBChzxjHVHQcpxhlHjVwqsR/H1CTds+HPm9dyTLrE o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxAAAlWKla/5pdJa1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNQgVUoCoNGihqNc4IDgRaUNhSBfwqFEQIagwwhNBgBAgE?= =?us-ascii?q?BAQEBAQJrKIUlAQEBAwEjEUMCBQsCAQgVAwICCAEaAwICAjAUARACBA4FCIU?= =?us-ascii?q?ICK0zgiaIYYIMgQ2EIYIUgVWBVIMghFMBEgEJLSOCToJiBJpYCQKJUocGgW2?= =?us-ascii?q?HSoU0h3aJMAIREwGBKwEeOGFxcBWCfYIzHI4gd40DBQoYA4EHgRgBAQE?=
X-IronPort-AV: E=Sophos;i="5.48,306,1517875200"; d="scan'208";a="368873509"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2018 17:14:53 +0000
Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w2EHEqf5012554 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Mar 2018 17:14:53 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 14 Mar 2018 13:14:52 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Wed, 14 Mar 2018 13:14:52 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Andy Bierman <andy@yumaworks.com>
CC: Martin Bjorklund <mbj@tail-f.com>, "alex@clemm.org" <alex@clemm.org>, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <rwilton@cisco.com>, "kwatsen@juniper.net" <kwatsen@juniper.net>, "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-subscribed-notifications@ietf.org" <draft-ietf-netconf-subscribed-notifications@ietf.org>
Thread-Topic: [Netconf] LC on subscribed-notifications-10
Thread-Index: AQHTuiDhP4UPxNeFY0CSJ8tCCoPN1aPM98TAgAK21ACAAAhYEIAAUPqA///MxoCAAGPMAP//wI7g
Date: Wed, 14 Mar 2018 17:14:51 +0000
Message-ID: <c5e2a83df6644c72a1347af93b90fa90@XCH-RTP-013.cisco.com>
References: <8d4f4193c6694fe387d284d7b74c9b09@XCH-RTP-013.cisco.com> <20180314.093900.1449292548839197417.mbj@tail-f.com> <379cfb19a5c64753a067a2ae42f65a82@XCH-RTP-013.cisco.com> <20180314.145841.72164558423482638.mbj@tail-f.com> <9b8cf6b9e6114e00800525db71505023@XCH-RTP-013.cisco.com> <CABCOCHSzcFg81LZPRhV5toN2x48AqbPk8CCt4Y-4B_GT1OrHkg@mail.gmail.com>
In-Reply-To: <CABCOCHSzcFg81LZPRhV5toN2x48AqbPk8CCt4Y-4B_GT1OrHkg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Lb74Yx3JE7aVYDchwzsfh4bI5Ns>
Subject: Re: [Netconf] LC on subscribed-notifications-10
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Mar 2018 17:14:57 -0000

(Look for <Eric2>  trying to keep things legible for those using text only email clients)

From: Andy Bierman, March 14, 2018 12:53 PM

On Wed, Mar 14, 2018 at 8:35 AM, Eric Voit (evoit) <mailto:evoit@cisco.com> wrote:
(reducing to the single open item, and adding Andy + Alex to the "to")

> From: Martin Bjorklund, March 14, 2018 9:59 AM
>
> Hi,
>
> "Eric Voit (evoit)" <mailto:evoit@cisco.com> wrote:
> > Hi Martin,
> >
> > But for
> > subscription to event streams, it is assumed that any event records
> > placed on a stream permitted for that receiver is authorized content
> > (just like RFC-5277).
>
> Hmm.  This is not how it is defined in RFC 5277:

Agree.   I should not have said "just like 5277".   More below.

>    After generation of the <notification> element, access control is
>    applied by the server.  If a session does not have permission to
>    receive the <notification>, then it is discarded for that session,
>    and processing of the internal event is completed for that session.
>
> Also, NACM is designed to drop notifications that the client doesn't have
> access to.

A few years ago during early discussions, Alex and I remember Andy asking that per receiver access control not be applied to traffic coming out of a stream.    We took that to mean that a receiver should get all the event records on a stream, without any per-notification filtering.  This is what drove the current text.

Per RFC-6536, section 3.4.6., the outgoing <notification> authorization is able to look at the notification event type, and if a receiver is authorized to receive the notification event type, then it is also authorized to receive any data it contains.

Reconsidering this, perhaps Alex and I interpreted Andy's intent wrong.  And Andy actually requested the current event type behavior which NACM can currently perform on the RFC-5277 NETCONF event stream, but no other filtering of event records beyond that.

I think the notification event type filtering is still applicable.

<Eric2>  Based on this, I will add the relevant RFC-5277 text into subscribed notifications.  Look for a link to a draft version on github shortly.  Will send link to this thread.
</Eric2>

I remember some discussions about applying NACM to YANG Push subscriptions.
Of course the client needs permission to receive <push-update> events.
The issue for YP is that this is the only access control provided.

In order to support NACM for the contents of <push-update> events, the client
MUST have permission to read every data node specified in the filters for
a subscription. This is checked when the subscription is configured or activated.
If a filter-ref filter is changed so this is no longer true, then the server MUST
suspend or terminate the subscription.

IMO even this is quite an implementation burden, but less than having the
server check NACM rules for every descendant node of every edited node for every
<push-update>.

<Eric2> Agree that either is a valid method of achieving the requirements of yang-push.
</Eric2>

Eric2

If that is the case, and this capability is desired by the WG, Alex and I would be happy to replicate the relevant text from RFC-5277 section 3.2 to draft-ietf-netconf-subscribed-notifications to cover this.

Thanks,
Eric

Andy
 

> > Effects like this are why the two drafts, as well as the YANG model
> > targets and filters for datastores and to streams have been separated.
> >
> > > Your statement:
> > >
> > >   Access control is to the stream rather than the content.
> > >
> > > seems to imply that in order to subscribe to changes to the
> > > datastore, you need full access to all nodes covered by the filter.
> >
> > As a stream and a datastore are different, hopefully my comment above
> > clears this up.
> >
> > Eric
> > > /martin
>
>
> /martin