Subject: [Netconf] Subscription modified for RPC based subsscription [subscribed-notifications]

From: Balazs Lengyel <[email-masked]>
Date: Fri, 1 Dec 2017 17:10:58 +0100

Hello,

If a subscription uses a stored filter by-reference it is
possible for another party to maliciously or accidentally modify
the content of the stored filter. In this case the RPC-based
subscription is effectively modified without the subscriber
noticing it, which is a problem. To avoid this I would like

the subscriber to get a modified-subscription notification. It
is not clear in chapter "8.2.  subscription-modified"  whether a
notification would be sent in such a case for configured
subscriptions. However it is stated that no such notification is
sent for  for rpc-based subscriptions.  IMHO a notification is
needed in this case both for rpc-based and for configured
subscriptions.

or

it should be impossible to modify a filter if it is used by an
established subscription

Regards Balazs

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 1 Dec 2017 19:33:08 +0000

Hi Balazs,

What do you think about the following options:

(1) A filter retrieved via the leafref for a dynamic subscription is applied for the lifecycle of the subscription (unless modified via a specific modify-subscription RPC request driven from the subscriber.)     If an entry in the “filters” container is modified via configuration operations, this has no effect on any existing dynamic subscriptions.  It is up to the subscriber to know/retain the meaning of a filter from the time of subscription.

(2) It is not allowed to modify an entry in container “filters” wherever a specific identifier is used as a leafref by a dynamic subscription .   (I.e., your second option below.)

(3) A dynamic subscription receiver must listen for “Subscription-modified” in case of a configuration change of a filter provided by leafref.   (I.e., your first option below.)

I like (1), (2), and (3) in that order.  Note: The main reason I am hesitant about (3) is because (a) a dynamic subscriber is supposed to be fully in charge of the subscription policies, and local applications should not have to react to mid-stream policy changes they didn’t initiate, and (b) there is more complexity in several aspects.

Eric

P.S.: Independent of this issue for dynamic subscription, for configured subscriptions it is probably good to include the actual filter referenced from the filter container within the subscription-started or subscription-modified.  Right now, just a leafref is provided in those two notification.  And per your point, a subsequent get on that filter by-reference could have been changed.

From: Netconf [mailto:[email-masked]] On Behalf Of Balazs Lengyel
Sent: Friday, December 1, 2017 11:11 AM
To: [email-masked]
Subject: [Netconf] Subscription modified for RPC based subsscription [subscribed-notifications]

Hello,

If a subscription uses a stored filter by-reference it is possible for another party to maliciously or accidentally modify the content of the stored filter. In this case the RPC-based subscription is effectively modified without the subscriber noticing it, which is a problem. To avoid this I would like

  *   the subscriber to get a modified-subscription notification. It is not clear in chapter "8.2.  subscription-modified"  whether a notification would be sent in such a case for configured subscriptions. However it is stated that no such notification is sent for  for rpc-based subscriptions.  IMHO a notification is needed in this case both for rpc-based and for configured subscriptions.

or

  *   it should be impossible to modify a filter if it is used by an established subscription

Regards Balazs

--

Senior Specialist

Mobile: +36-70-330-7909              email: [email-masked]<mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 1 Dec 2017 20:47:50 +0100

What about this option:

(0) Do not allow dynamic subscriptions to use configured filters.

/js

> _______________________________________________
> Netconf mailing list
> [email-masked]
> 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         <http://www.jacobs-university.de/>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 1 Dec 2017 20:09:57 +0000

Hi Juergen,

> From: Juergen Schoenwaelder, December 1, 2017 2:48 PM
> 
> What about this option:
> 

Yes this is possible.  However some people have expressed a desire to pre-qualify filters so that it is known up-front that it won't be too computationally expensive.  Such pre-qualifying reduces potential filter errors, and reduces the need for complex run-time filter evaluations.

Eric

> > (1) A filter retrieved via the leafref for a dynamic subscription is applied
> for the lifecycle of the subscription (unless modified via a specific modify-
> subscription RPC request driven from the subscriber.)     If an entry in the
> “filters” container is modified via configuration operations, this has no
> effect on any existing dynamic subscriptions.  It is up to the subscriber to
> know/retain the meaning of a filter from the time of subscription.
> >
> > (2) It is not allowed to modify an entry in container “filters” wherever a
> specific identifier is used as a leafref by a dynamic subscription .   (I.e., your
> second option below.)
> >
> > (3) A dynamic subscription receiver must listen for “Subscription-
> modified” in case of a configuration change of a filter provided by leafref.
> (I.e., your first option below.)
> >
> > I like (1), (2), and (3) in that order.  Note: The main reason I am hesitant
> about (3) is because (a) a dynamic subscriber is supposed to be fully in
> charge of the subscription policies, and local applications should not have
> to react to mid-stream policy changes they didn’t initiate, and (b) there is
> more complexity in several aspects.
> >
> > Eric
> >
> > P.S.: Independent of this issue for dynamic subscription, for configured
> subscriptions it is probably good to include the actual filter referenced from
> the filter container within the subscription-started or subscription-
> modified.  Right now, just a leafref is provided in those two notification.
> And per your point, a subsequent get on that filter by-reference could have
> been changed.
> >
> > If a subscription uses a stored filter by-reference it is possible for another
> party to maliciously or accidentally modify the content of the stored filter.
> In this case the RPC-based subscription is effectively modified without the
> subscriber noticing it, which is a problem. To avoid this I would like
> >
> >   *   the subscriber to get a modified-subscription notification. It is not
> clear in chapter "8.2.  subscription-modified"  whether a notification would
> be sent in such a case for configured subscriptions. However it is stated that
> no such notification is sent for  for rpc-based subscriptions.  IMHO a
> notification is needed in this case both for rpc-based and for configured
> subscriptions.
> >
> > or
> >
> > Mobile: +36-70-330-7909              email:
> [email-masked]<mailto:[email-masked]>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 1 Dec 2017 21:53:37 +0100

> Yes this is possible.  However some people have expressed a desire to pre-qualify filters so that it is known up-front that it won't be too computationally expensive.  Such pre-qualifying reduces p…

I am not sure I understand. If these filters are _config_, then they
will be as efficient as any filter set as part of a dynamic stream
registration - both can be changed anytimeq. If they are hard-wired
filter, well, then they may be more efficient but then they are not
_config_ and likely not changeable via config.

So the third option is different entities configure filters and
clients use them (without actually understanding them), i.e., a split
of responsibilities. In that case, we may be asking for trouble unless
there is strong coordination between the entities configuring filters
and clients using the configured filters. I do not see the performance
gain, I do see a chance to introduce complexity and brittleness.

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 1 Dec 2017 22:01:15 +0000

> From: Juergen Schoenwaelder, December 1, 2017 3:54 PM
> 
> > Yes this is possible.  However some people have expressed a desire to pre-
> qualify filters so that it is known up-front that it won't be too
> computationally expensive.  Such pre-qualifying reduces potential filter
> errors, and reduces the need for complex run-time filter evaluations.
> >
> 
> I am not sure I understand. If these filters are _config_, then they will be as
> efficient as any filter set as part of a dynamic stream registration - both can
> be changed anytimeq.

Agree.  A filter provided by reference, and a filter pre-configured by an operator will be equally efficient.

> If they are hard-wired filter, well, then they may be
> more efficient but then they are not _config_ and likely not changeable via
> config.

It is possible for a vendor to make hard-wired filters.  But as far as I know, this has not been deeply considered at this point.
 
> So the third option is different entities configure filters and clients use them
> (without actually understanding them), i.e., a split of responsibilities. In that
> case, we may be asking for trouble unless there is strong coordination
> between the entities configuring filters and clients using the configured
> filters. I do not see the performance gain, I do see a chance to introduce
> complexity and brittleness.

The benefit is not from the performance gain.  The benefit is from pre-qualification and pre-testing on the part of an operator -- i.e., the operator pre-determined that the performance profile of this particular configured filter makes it safe for this particular filter to be exposed for subscription.    As an example think of an interfaces container which is populated with physical and logical interfaces.  The operator might choose to default reject any dynamic subscriptions which refer to interfaces *except* where they have pre-tested the filter, and the filter has been proven to only select physical interface status.

There is also some benefit for abstracting platform specific variations.  For example a pre-configured filter-id of "physical-interface-status" could be made available for subscription.  The actual contents of this filter could be customized and pre-positioned for a platform+release.  This lets new interfaces be populated, and the filters enhanced without the applications/subscribers from also having to tweak their requests in order to stay in concert with each publisher software upgrade.  The publisher (which knows more about its data structures) has the option of what to expose.

Eric

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 1 Dec 2017 14:52:26 -0800

Hi -

On 12/1/2017 11:33 AM, Eric Voit (evoit) wrote:
> (1) A filter retrieved via the leafref for a dynamic subscription is 
> applied for the lifecycle of the subscription (unless modified via a 
> specific modify-subscription RPC request driven from the subscriber.) 
>      If an entry in the “filters” container is modified via 
> configuration operations, this has no effect on any existing dynamic 
> subscriptions.  It is up to the subscriber to know/retain the meaning of 
> a filter from the time of subscription.

I hate this, but if this is the preferred approach, it should be
aligned with NMDA to reflect the configuration/operational split.

> (2) It is not allowed to modify an entry in container “filters” wherever 
> a specific identifier is used as a leafref by a dynamic subscription .   
> (I.e., your second option below.)

Awful.  How does the administrator who needs to update a filter figure
out which subscriptions need to be killed before he/she can do the
update?

> (3) A dynamic subscription receiver must listen for 
> “Subscription-modified” in case of a configuration change of a filter 
> provided by leafref.   (I.e., your first option below.)

Cleaner, but I'd question the need for "must" here.  A subscriber's
use of pre-configured filters presumes a trust relationship between
the subscriber and all who have the ability to modify those filters.
If there is no such relationship (i.e., the filter might be changed
in ways incompatible with the subscriber's goals) then the use of
the pre-configured filter is inappropriate.

> I like (1), (2), and (3) in that order.  Note: The main reason I am 
> hesitant about (3) is because (a) a dynamic subscriber is supposed to be 
> fully in charge of the subscription policies, and local applications 
> should not have to react to mid-stream policy changes they didn’t 
> initiate, and (b) there is more complexity in several aspects.
> 
> Eric
...

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 1 Dec 2017 15:52:46 -0800

Hi,

Why would a filter-ref be any different for a dynamic vs. configured
subscription?
The draft needs to state whether it means by reference or by value.

If by reference, then any change in a configured filter is immediately
applied to all
subscriptions using this filter.  If by value, then how does a configured
subscription
ever get changed? If by value, then a <modify-subscription> could be
required
for dynamic subscriptions. Does that mean <edit-config> would be required
to modify a configured subscription?

Seems to me the only interpretation that makes sense is that a filter-ref is
by reference to a shared filter. If the filter is deleted, then all
subscriptions behave
as if that filter-ref is disabled and ignored.

Andy

On Fri, Dec 1, 2017 at 2:52 PM, Randy Presuhn <
[email-masked]> wrote:

>>     If an entry in the “filters” container is modified via configuration
>> operations, this has no effect on any existing dynamic subscriptions.  It
>> is up to the subscriber to know/retain the meaning of a filter from the
>> time of subscription.
>>
>
>> specific identifier is used as a leafref by a dynamic subscription .
>> fully in charge of the subscription policies, and local applications should
>> not have to react to mid-stream policy changes they didn’t initiate, and
>> (b) there is more complexity in several aspects.
>>
>> Eric
>>
> ...
>
> Randy
>

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 1 Dec 2017 16:55:51 -0800

Hi -

> Why would a filter-ref be any different for a dynamic vs. configured 

I see no reason to treat them differently.

> The draft needs to state whether it means by reference or by value.

Reference makes sense to me; I was rather taken aback by option (1)
which would effectively treat as call-by-value.

> applied to all > subscriptions using this filter.

Makes total sense to me.  It's also reasonable because the decision
to refer to a filter presumes a trust relationship between the filter's
user and whatever has the authority to change that filter.

> If by value, then how does a 
> configured subscription

Agree, the "call-by-value" approach seems to me to be fraught with
complications that do not improve the overall manageability of the
system.

> as if that filter-ref is disabled and ignored.

Seems very sensible to me.

> Andy

You pretty much summed up my thinking behind my "hate this" reaction
to option (1).

Randy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Sat, 2 Dec 2017 20:02:12 +0000

My take on the exchange is that Randy, Balazs, and Andy all would prefer that a modify-subscription notification be allowed for a dynamic subscription where there is a shared filter.  This would allow a change of a referenced filter identifier to be driven through all subscriptions identically.    I will make the change.

Eric

From: Andy Bierman, December 1, 2017 6:53 PM

Hi,

Why would a filter-ref be any different for a dynamic vs. configured subscription?
The draft needs to state whether it means by reference or by value.

If by reference, then any change in a configured filter is immediately applied to all
subscriptions using this filter.  If by value, then how does a configured subscription
ever get changed? If by value, then a <modify-subscription> could be required
for dynamic subscriptions. Does that mean <edit-config> would be required
to modify a configured subscription?

Seems to me the only interpretation that makes sense is that a filter-ref is
by reference to a shared filter. If the filter is deleted, then all subscriptions behave
as if that filter-ref is disabled and ignored.

Andy

On Fri, Dec 1, 2017 at 2:52 PM, Randy Presuhn <[email-masked]<mailto:[email-masked]>> wrote:
Hi -

Eric
...

Randy

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 3 Dec 2017 10:31:11 +0100

> The benefit is not from the performance gain.  The benefit is from pre-qualification and pre-testing on the part of an operator -- i.e., the operator pre-determined that the performance profile of…

This means that the client has to trust the filter to be meaningful
and that the entity configuring the filter understands the impact of
filter changes on all clients. This can lead to interesting surprises.
I have no clue whether operators run networks this way. How does a
client select the right filter for its purpose? By a 'well-known'
name? Or by reading all filters and analyzing the xpath whether one of
them matches its requirements? I doubt the later, so you likely have a
more or less fragile name binding. I assume things are simpler and
more robust if clients set the filters they need instead of relying on
a third party.

> There is also some benefit for abstracting platform specific variations.  For example a pre-configured filter-id of "physical-interface-status" could be made available for subscription.  The actual…

You seem to assume that such a filter would have to list all physical
interfaces and hence some (manual?) adoption would be needed whenever
a linecard is inserted/removed. Would it not be simpler and more
robust if an app interested in physical layer interface status changes
simply sends the correct filter it needs (which would test that the
if:lower-layer-if leaflist is empty in this case)?

Perhaps I am just too much a fan of loose coupling, I would not write
clients to rely on filters provided by 3rd parties. As long as that
can be done, I do not care so much how tight coupling fans deal with
the consequences of their designs. ;-)

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Sun, 3 Dec 2017 14:49:28 +0000

> From: Juergen Schoenwaelder, December 3, 2017 4:31 AM
> 
> > The benefit is not from the performance gain.  The benefit is from pre-
> qualification and pre-testing on the part of an operator -- i.e., the operator
> pre-determined that the performance profile of this particular configured
> filter makes it safe for this particular filter to be exposed for subscription.
> As an example think of an interfaces container which is populated with
> physical and logical interfaces.  The operator might choose to default reject
> any dynamic subscriptions which refer to interfaces *except* where they
> have pre-tested the filter, and the filter has been proven to only select
> physical interface status.
> >
> 
> This means that the client has to trust the filter to be meaningful and that
> the entity configuring the filter understands the impact of filter changes on
> all clients. This can lead to interesting surprises.

Yes, surprises can certainly happen in this case.    In the end for a particular type of resource intensive filter an operator will face the choice of either:

(a) allowing an RPC which chooses a pre-configured, pre-tested filter, or

(b) not allowing an RPC which is providing its own filter because its CPU impacts cannot be adequately ascertained at run-time. 

> I have no clue whether operators run networks this way. How does a client
> select the right filter for its purpose? By a 'well-known'
> name? 

Yes, this way.    I see some parallels in this with SNMP traps -- in that they both include pre-defined logic which can be selected/invoked at runtime.  A big difference from SNMP traps however is that an Operator has the option of developing, testing, and pre-positioning this logic.

> Or by reading all filters and analyzing the xpath whether one of them
> matches its requirements? I doubt the later, so you likely have a more or
> less fragile name binding. 

Agree. I don't think this will be likely.

> I assume things are simpler and more robust if
> clients set the filters they need instead of relying on a third party.

Yes, this is simpler.   And in no way is this option being prohibited.
 
> > There is also some benefit for abstracting platform specific variations.  For
> example a pre-configured filter-id of "physical-interface-status" could be
> made available for subscription.  The actual contents of this filter could be
> customized and pre-positioned for a platform+release.  This lets new
> interfaces be populated, and the filters enhanced without the
> applications/subscribers from also having to tweak their requests in order
> to stay in concert with each publisher software upgrade.  The publisher
> (which knows more about its data structures) has the option of what to
> expose.
> 
> a linecard is inserted/removed. Would it not be simpler and more robust if
> an app interested in physical layer interface status changes simply sends
> the correct filter it needs (which would test that the if:lower-layer-if leaflist
> is empty in this case)?

Yes, this would be simpler.   

One thing in the back of my mind though is that the definition of correct might change without the client knowing. This has the potential of leaving clients more susceptible to server upgrades where new object instances are exposed, and these objects are suddenly and mistakenly selected.

This could of course also happen with pre-positioned filters.  But many of these errors may be caught as part of publisher testing. 
 
> Perhaps I am just too much a fan of loose coupling, I would not write clients
> to rely on filters provided by 3rd parties. As long as that can be done, I do
> not care so much how tight coupling fans deal with the consequences of
> their designs. ;-)

Thanks, and I do appreciate this discussion.  As nothing being proposed is stopping filters from being provided dynamically in the RPC, loose coupling options are there.

Eric

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 4 Dec 2017 10:07:57 +0100

Hello Eric,

Yes my preferred solution is a modify-subscription notification
even for a dynamic subscription.

I assume the client will not have to separately subscribe to this
notification as it is a trivial need.

regards Balazs

On 2017-12-02 21:02, Eric Voit (evoit)
wrote:

My
take on the exchange is that Randy, Balazs, and Andy all
would prefer that a modify-subscription notification be
allowed for a dynamic subscription where there is a shared
filter.  This would allow a change of a referenced filter
identifier to be driven through all subscriptions
identically.    I will make the change.

Eric

From:
Andy Bierman, December 1, 2017 6:53 PM

Hi,

Why would a filter-ref be any
different for a dynamic vs. configured subscription?

The draft needs to state whether it
means by reference or by value.

If by reference, then any change in a
configured filter is immediately applied to all

subscriptions using this filter.  If
by value, then how does a configured subscription

ever get changed? If by value, then a
<modify-subscription> could be required

for dynamic subscriptions. Does that
mean <edit-config> would be required

Seems to me the only interpretation
that makes sense is that a filter-ref is

by reference to a shared filter. If
the filter is deleted, then all subscriptions behave

as if that filter-ref is disabled and
ignored.

Andy

On Fri, Dec 1, 2017 at 2:52 PM,
Randy Presuhn <[email-masked]>
wrote:

Hi -

Hi Balazs,

(1) A filter retrieved via the leafref for a
dynamic subscription is applied for the
lifecycle of the subscription (unless modified
via a specific modify-subscription RPC request
driven from the subscriber.)      If an entry in
the “filters” container is modified via
configuration operations, this has no effect on
any existing dynamic subscriptions.  It is up to
the subscriber to know/retain the meaning of a
filter from the time of subscription.

I hate this, but if this is the preferred
approach, it should be

aligned with NMDA to reflect the
configuration/operational split.

(2) It is not allowed to
modify an entry in container “filters” wherever
a specific identifier is used as a leafref by a
dynamic subscription .   (I.e., your second
option below.)

Awful.  How does the administrator who needs to
update a filter figure

out which subscriptions need to be killed before
he/she can do the

update?

(3) A dynamic subscription
receiver must listen for “Subscription-modified”
in case of a configuration change of a filter
provided by leafref.   (I.e., your first option
below.)

Cleaner, but I'd question the need for "must"
here.  A subscriber's

use of pre-configured filters presumes a trust
relationship between

the subscriber and all who have the ability to
modify those filters.

If there is no such relationship (i.e., the filter
might be changed

in ways incompatible with the subscriber's goals)
then the use of

I like (1), (2), and (3) in
that order.  Note: The main reason I am hesitant
about (3) is because (a) a dynamic subscriber is
supposed to be fully in charge of the
subscription policies, and local applications
should not have to react to mid-stream policy
changes they didn’t initiate, and (b) there is
more complexity in several aspects.

Eric

...

Randy

Netconf mailing list

[email-masked]