Re: [Netconf] [SPAM?] RE: LC on subscribed-notifications-10

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Sun, 18 March 2018 13:54 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 2B18212711A; Sun, 18 Mar 2018 06:54:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 nZJVotJTOwk4; Sun, 18 Mar 2018 06:53:58 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C3B126C0F; Sun, 18 Mar 2018 06:53:58 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A9575EAF; Sun, 18 Mar 2018 14:53:56 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id XUMRszFqBa_E; Sun, 18 Mar 2018 14:53:55 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sun, 18 Mar 2018 14:53:56 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 52B7E20014; Sun, 18 Mar 2018 14:53:56 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 235D_Qg1PqLE; Sun, 18 Mar 2018 14:53:55 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2918620013; Sun, 18 Mar 2018 14:53:55 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 836E24274AA0; Sun, 18 Mar 2018 14:53:54 +0100 (CET)
Date: Sun, 18 Mar 2018 14:53:54 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Rohit R Ranade <rohitrranade@huawei.com>
Cc: "alex@clemm.org" <alex@clemm.org>, 'Andy Bierman' <andy@yumaworks.com>, "'Eric Voit (evoit)'" <evoit@cisco.com>, "draft-ietf-netconf-subscribed-notifications@ietf.org" <draft-ietf-netconf-subscribed-notifications@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Message-ID: <20180318135354.udwvr5cqpy2m4lmr@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Rohit R Ranade <rohitrranade@huawei.com>, "alex@clemm.org" <alex@clemm.org>, 'Andy Bierman' <andy@yumaworks.com>, "'Eric Voit (evoit)'" <evoit@cisco.com>, "draft-ietf-netconf-subscribed-notifications@ietf.org" <draft-ietf-netconf-subscribed-notifications@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
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> <041f01d3be9f$c73a2370$55ae6a50$@clemm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: NeoMutt/20171215
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/3L95EbWIITxWerjgux6zXDHUYUA>
Subject: Re: [Netconf] [SPAM?] RE: 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: Sun, 18 Mar 2018 13:54:01 -0000

Hi,

NACM (RFC 8341 by now) should not try to cover all future protocol
mechanisms to access data. NACM has a generic processing model
(section 3.1.3 in RFC 8341) and protocols and implementations must
make sure they follow this model.

If implementations choose to terminate subscriptions since processing
NACM read access rules is considered to be too costly, then they need
to figure out how to do this correctly. This is not something NACM has
to talk about. If at all this is a subscription specific "optimization".

Instead of adding more protocol specific text to NACM, I believe we
should do the opposite, remove protocol specific text from NACM (if
we ever update RFC 8341).

/js

On Sun, Mar 18, 2018 at 01:15:56PM +0000, Rohit R Ranade wrote:
> Hi Alex,
> 
> 1. If this is a push update specific point, the newly updated Nacm rfc need to mention this point specifically.
> 2. If a session had subcribed to multiple paths and it was ok, but another session added a deny rule for one of the path, are all subscriptions dropped ? how will user know what caused the termination.we may need to add to the subscription termination list
> 3. also when a nacm read-deny rule is configured, we may need to scan through all filters and terminate accordingly.. whether the nacm rfc can mention this point
> From:alex@clemm.org
> To:Rohit R Ranade,'Andy Bierman','Eric Voit (evoit)',
> Cc:draft-ietf-netconf-subscribed-notifications@ietf.org,netconf@ietf.org,
> Date:2018-03-18 15:29:20
> Subject:RE: [SPAM?] RE: [Netconf] LC on subscribed-notifications-10
> 
> Hi Rohit,
> 
> Yes.  Conceptually, it is cleanest to apply the filter on the event contents with each update.  At the same time, in the interest of performance, Andy and others have raised the issue of performance penalty if every update has to be subjected to a filter.  One option is for an implementation to simply reject a subscription if there is a chance that it might contain information that would have to be filtered (i.e. do the NACM check at the time the subscription is created), and in case of NACM changes later that might affect subscriptions, to terminate the subscription (and let users resubscribe).
> 
> --- Alex
> 
> From: Rohit R Ranade <rohitrranade@huawei.com>
> Sent: Saturday, March 17, 2018 9:59 PM
> To: Andy Bierman <andy@yumaworks.com>; Eric Voit (evoit) <evoit@cisco.com>
> Cc: draft-ietf-netconf-subscribed-notifications@ietf.org; alex@clemm.org; netconf@ietf.org
> Subject: [SPAM?] RE: [Netconf] LC on subscribed-notifications-10
> 
> hi all,
> 
> If user has permission to read on parent but not child, and if user has subscription filter on parent, the user should be able to get changes on parent ONLY even if both parent and child were modified..
> So I feel nacm rules need to be applied at the time of generating push updates..user should not get any updates if only child is updated.. this will be my expectation as an user..
> 
> From:Andy Bierman
> To:Eric Voit (evoit),
> Cc:draft-ietf-netconf-subscribed-notifications@ietf.org,alex@clemm.org,netconf@ietf.org,
> Date:2018-03-14 22:23:10
> Subject:Re: [Netconf] LC on subscribed-notifications-10
> 
> 
> 
> On Wed, Mar 14, 2018 at 8:35 AM, Eric Voit (evoit) <evoit@cisco.com<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)" <evoit@cisco.com<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.
> 
> 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>.
> 
> 
> 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
> 

> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>