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

<alex@clemm.org> Sun, 18 March 2018 09:59 UTC

Return-Path: <alex@clemm.org>
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 2757E127077; Sun, 18 Mar 2018 02:59:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] 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 aKddby7VqoiY; Sun, 18 Mar 2018 02:59:19 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 150891200A0; Sun, 18 Mar 2018 02:59:18 -0700 (PDT)
Received: from LAPTOPR7T053C2 ([31.55.42.197]) by mrelay.perfora.net (mreueus001 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MBTkG-1en1Uh2bZe-00AXaD; Sun, 18 Mar 2018 10:59:10 +0100
From: <alex@clemm.org>
To: "'Rohit R Ranade'" <rohitrranade@huawei.com>, "'Andy Bierman'" <andy@yumaworks.com>, "'Eric Voit \(evoit\)'" <evoit@cisco.com>
Cc: <draft-ietf-netconf-subscribed-notifications@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> 6ADBF186-A27B-4180-9F31-6E83A709D685
In-Reply-To: 6ADBF186-A27B-4180-9F31-6E83A709D685
Date: Sun, 18 Mar 2018 02:59:14 -0700
Message-ID: <041f01d3be9f$c73a2370$55ae6a50$@clemm.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0420_01D3BE65.1ADC83F0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHTsOkg7dgRFAAsnEKJm2WNvwigIKPMWckAgABY54CAAkUtAIAAUQOAgAAIT4CAABsogIAAFWoAgAYH/LaAAFKgkA==
Content-Language: en-us
X-Provags-ID: V03:K0:DJmC0qVHjUZ14/sdVv0QkzzZQ+crAPb6XYsaIcuRQ7NBwI2wYte BBAUtLQJvbTJGDk3qkqtGCAU+ZmU/td7o2kTRo1sU4TWutjoPCGieV5DPykATfGVFcQ54py zW7eW2hLZTsenCobbBX+3R6Dc1ZE4LwVGBIN2DyV3GpLbJnrlj9OGsNDpDu9WiP+ltPtYLO hCSeEiyml7BI9e+FmhiaQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:1Wc/fDu9/mU=:0jN46M9oJVokevuk0BvRxO F+xX392HmSeEbwkkgxBByjevrokp4ym/h/Z5oSAsJ8mPU/nr/iiCGN4Rcdi4pHMl1zucyYaWD egUDMSEtGmWxdRJxpkrgJf37HQFzkYFH+eJhpVmqOR+8ILRdYTkMY4OfQ93YF/XrckyLbv64/ kZM72GePSxlgSflh0/zSFS8BIWk6j8+l5CIUwi7LUI2azWsQqzGKQe0lQUXVM6wff9Pwnn8r8 rx8AVxfTnQUPkWPOIDwWpmiM0ZJ9W3zTgH1c7yQKGYMbI5IhWAgov29hPbKo+vVmuolRJfArf xlpwbf2tlZwApZEoQe8qaVwrTBkGbAYua2e6O6/UhO0fq4T8orLe1N1kM8KF/mZRw2ug2FHjO R/hNe7rY1mm46AeYQJQ24Qt59qgXxkFH039IgusximqEjK8ZTpxO7n8WYstDrnDFviHowzVxd GLs0o4Zu/k7hL+UOqtDXldxFDhe7G85PE+jnOXGjYouFnBikKpHXcR77UNQTv7fgXTz5baXpQ Q1PugSE1nOaFHKXuE2hr8G1p2SLviFke4yMNMmwEw+hvTR16VC5nmjnOR9G83A4Cwt/HbGGdc DiZAmZwD97qthzOL16ngGU9uyePQDCum/9UZ4mxVRoOmyt0PeEbZARYbIr4BjH+g8+CXP3qrD RfpdO+N3cfkyoGlFELhwohlMbEwKrQyAkNbeJbkTumI6RChCqS2VuKFJtHTVUtI6Ca489Vn39 6fdPi8rhqvdMnzayJHmAnEXB1u00TZZPpPeSLNMkGQ9zNC9Bewz8rBfoB/M=
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/fvZAl_9MU8vJJ-me43ZmAhM52uc>
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 09:59:25 -0000

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,netco
nf@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