Subject: [netmod] How to prevent a client from modifying the type of an interface?

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 29 Nov 2016 14:58:10 +0000

Hi,

We're trying to figure out how to prevent a NC client from changing the type
of an interface.  Assume that we have an interface stack defined and the
lowest layer of the stack (the physical interface) is of type fastdsl.   In
principle a NC client can send an edit-config to the server and change the
type of that interface to something else.  It is still a valid YANG model
but it does not make any sense any more.  Is there a way to express in YANG
that this type of change is not allowed rather than having some SW
application in the device interacting with the NC server and responding with
an error to avoid this change?  The server just can't ignore this change and
leave the type as it was since then the client and the server are no longer
aligned.

Best regards - Vriendelijke groeten,

Bart Bogaert

Broadband-Access System Architect Data

Contact number +32 3 2408310 (+32 477 673952)

NOKIA

Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis 220-0002334-42
VAT BE 0404 621 642 Register of Legal Entities Antwerp

<<
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law. If
you are not the intended recipient, you should delete this message. Any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited without the prior consent of its
author.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 29 Nov 2016 10:05:49 -0500

We ran into a version of this in the SUPA model.  Every grouping has a 
leaf with a default value (entity-class).  That entity-lass value is 
correct by default, and must not be changed.
However, it is also over-ridden in refines statements and its primary 
use is in MUST clauses.
As such, it can not be config-false.

So we settled for a comment telling folks not to change it.
If there is a better answer, I would be happy to hear it.

Yours,
Joel

On 11/29/16 9:58 AM, Bogaert, Bart (Nokia - BE) wrote:
> Hi,
>
>
>
> We’re trying to figure out how to prevent a NC client from changing the
> type of an interface.  Assume that we have an interface stack defined
> and the lowest layer of the stack (the physical interface) is of type
> fastdsl.   In principle a NC client can send an edit-config to the
> server and change the type of that interface to something else.  It is
> still a valid YANG model but it does not make any sense any more.  Is
> there a way to express in YANG that this type of change is not allowed
> rather than having some SW application in the device interacting with
> the NC server and responding with an error to avoid this change?  The
> server just can’t ignore this change and leave the type as it was since
> then the client and the server are no longer aligned.
>
>
>
> *NOKIA*
> This message (including any attachments) contains confidential
> information intended for a specific individual and purpose, and is
> protected by law. If you are not the intended recipient, you should
> delete this message. Any disclosure, copying, or distribution of this
> message, or the taking of any action based on it, is strictly prohibited
> without the prior consent of its author.
>>>
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Nov 2016 16:18:33 +0100

> leave the type as it was since then the client and the server are no longer

The server has to reject edits that can't be applied to the hardware
that is present. Changing fastdsl to ethernet likely would be such a
change that can't be applied. Despite of this, you can of course
configure access control such that attempts to modify the interface
type will be reject. But access control is an added feature; a NC
implementation still needs to be able to deal with config change
requests that cannot be applied to the resources that are present.

> action based on it, is strictly prohibited without the prior consent of its

I assume there is consent by the author that the IETF archives these
messages since the author has read the Note Well...

/js

-- 
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: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 29 Nov 2016 15:22:39 +0000

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: 29 November 2016 16:19
To: Bogaert, Bart (Nokia - BE) <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] How to prevent a client from modifying the type of an
interface?

On Tue, Nov 29, 2016 at 02:58:10PM +0000, Bogaert, Bart (Nokia - BE) wrote:
> Hi,
> 
> We're trying to figure out how to prevent a NC client from changing 
> the type of an interface.  Assume that we have an interface stack defined
and the
> principle a NC client can send an edit-config to the server and change 
> the type of that interface to something else.  It is still a valid 
> YANG model but it does not make any sense any more.  Is there a way to 
> express in YANG that this type of change is not allowed rather than 
> having some SW application in the device interacting with the NC 
> server and responding with an error to avoid this change?  The server 
> just can't ignore this change and leave the type as it was since then 
> the client and the server are no longer aligned.
> 

The server has to reject edits that can't be applied to the hardware that is
present. Changing fastdsl to ethernet likely would be such a change that
can't be applied. Despite of this, you can of course configure access
control such that attempts to modify the interface type will be reject. But
access control is an added feature; a NC implementation still needs to be
able to deal with config change requests that cannot be applied to the
resources that are present.

[Bart Bogaert] We're looking for a way to prevent this with YANG but to be
honest I did not find a way on how to do that.

> message, or the taking of any action based on it, is strictly 
> prohibited without the prior consent of its author.

I assume there is consent by the author that the IETF archives these
messages since the author has read the Note Well...
[Bart Bogaert] I will remove that message from the footer when sending tot
the IETF mailing list...

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 29 Nov 2016 16:31:00 +0100

> On 29 Nov 2016, at 15:58, Bogaert, Bart (Nokia - BE) <[email-masked]> wrote:
> 
> Hi,
>  
> We’re trying to figure out how to prevent a NC client from changing the type of an interface.  Assume that we have an interface stack defined and the lowest layer of the stack (the physical interface) is of type fastdsl.   In principle a NC client can send an edit-config to the server and change the type of that interface to something else.  It is still a valid YANG model but it does not make any 

The description for the "type" leaf in ietf-interfaces says:

If a client tries to set the type of an interface to a
value that can never be used by the system, e.g., if the
type is not supported or if the type does not match the
name of the interface, the server MUST reject the request.

Lada

> sense any more.  Is there a way to express in YANG that this type of change is not allowed rather than having some SW application in the device interacting with the NC server and responding with an error to avoid this change?  The server just can’t ignore this change and leave the type as it was since then the client and the server are no longer aligned.
>  
> This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited without the prior consent of its author.
> >>
>  

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 29 Nov 2016 15:37:29 +0000

If a client tries to set the type of an interface to a value that can never be used by the system, e.g., if the type is not supported or if the type does not match the name of the interface, the server MUST reject the request.

[Bart Bogaert] Ok.  That is very clear but the NETCONF server can only reject if 1. there are rules in the YANG model that allow this, 2. An external application involved in the transaction tells the NC server in the box that this change is not allowed.  We are actually looking for a solution whereby the client, by using the device YANG model, can know (from YANG rules) that this change is not allowed.  For now I have not found such a solution to express this in YANG.  Having these kind of checks hidden from the client actually makes the device less programmable as the client needs to have a connection with the device.  For devices that are not always on and the client wants to accept changes on behalf of the device (which get forwarded when the device is powered up again) it would be good to have a great deal of certainty that the already accepted configuration by the client will also be accepted by the server.

Bart

Lada

> Broadband-Access System Architect Data Contact number +32 3 2408310 
> (+32 477 673952)
>  
> NOKIA
> Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE 
> 0404 621 642 Register of Legal Entities Antwerp
> 
> <<

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Nov 2016 16:54:26 +0100

> [Bart Bogaert] Ok.  That is very clear but the NETCONF server can only reject if 1. there are rules in the YANG model that allow this, 2. An external application involved in the transaction tells t…

There will always be errors possible - assuming a 'client' can
accurately predict all possible errors that can occure when a
configuration is applied on a server is somewhat hopeless. That said,
a server could perhaps announce a deviation that restricts the
possible set of values. But for anything more advanced than a simple
home router where you have hot swappable interfaces, this likely falls
apart quickly again.

Not every configuration that is valid according to YANG validation
rules and constraints is guaranteed to be applied successfully on a
given server with specific resources. With deviations, a server may
announce additional constraints that it has and client side tools may
make use of these deviations to do additional checks before attempting
an edit-config but the ultimate truth is when you send the edit-config
to the server and the change finally gets applied - or not.

/js

---

From: Robert Wilton <[email-masked]>
Date: Tue, 29 Nov 2016 16:15:51 +0000

Hi,

> to the server and the change finally gets applied - or not.
There are other cases where values can be set, but once set they cannot 
be changed.

Part of me would like to suggest a YANG extension that can be used on a 
leaf to indicate that its value cannot be changed unless a specified 
parent node is deleted.  E.g. in this case the extension could indicate 
that the configured interface itself must be deleted if the type is changed.

But perhaps the real judgement call here is whether the additional 
complexity involved with adding such an extension is worth the benefit 
that it brings over a well worded description.

Further, I'm not even sure that it is a given that for all interfaces on 
all devices that the interface type can never change. So, I suspect that 
most YANG clients will just end up being hard coded to know not to try 
and change the type of interface (unless it is allowed).  The simple 
approach might also be the best ...

Rob

---

From: Jan Lindblad <[email-masked]>
Date: Tue, 29 Nov 2016 17:18:59 +0100

Bart,

Jürgen et al are of course right in what they say, but if you really want to use YANG to enable a manager to know a priori what values are possible for a particular leaf somewhere, that's easy too -- if you see the addition of a new proprietary YANG module as a possibility.

module device-limitations {
...
  container limitations {
    must "not(/if:interfaces/if:interface[not(if:type='ianaift:fastdsl')])" {
      error-message "There must not be any interfaces that are not of fastdsl interface type";
    }
  }
}

There are also ways to do similar things without hardcoding the value(s) in the YANG, e.g. in factory default data or controlled by licenses. The acceptable values would sit in a system controlled list (i.e. operator writes prevented by NACM).

/jan

> On 29 nov. 2016, at 16:54, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/ <http://www.jacobs-university.de/>>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 29 Nov 2016 17:23:19 +0100

> On 29 Nov 2016, at 16:37, Bogaert, Bart (Nokia - BE) <[email-masked]> wrote:
> 
>> 
>> Hi,
>> 
> [Bart Bogaert] Ok.  That is very clear but the NETCONF server can only reject if 1. there are rules in the YANG model that allow this, 2. An external application involved in the transaction tells the NC server in the box that this change is not allowed.  We are actually looking for a solution whereby the client, by using the device YANG model, can know (from YANG rules) that this change is not allowed.  For now I have not found such a solution to express this in YANG.  Having these kind of checks hidden from the client

It's not hidden from the client, and the descriptions in YANG modules are normative. Yes, I understand you want a machine-readable rule but YANG simply cannot have a formalism for capturing all possible semantic constraints. One thing that might help a bit (at least make it more explicit) is to derive an identity from "interface-type", say "physical-interface", and state that interface types derived from it are read-only.

Lada

>  actually makes the device less programmable as the client needs to have a connection with the device.  For devices that are not always on and the client wants to accept changes on behalf of the device (which get forwarded when the device is powered up again) it would be good to have a great deal of certainty that the already accepted configuration by the client will also be accepted by the server.
> 
> Bart
> 
> Lada
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Nov 2016 08:36:46 -0800

Hi,

I agree with Jan -- NACM already exists to prevent clients from accessing
specific data nodes.

Andy

On Tue, Nov 29, 2016 at 8:18 AM, Jan Lindblad <[email-masked]> wrote:

> Bart,
>
> Jürgen et al are of course right in what they say, but if you really want
> to use YANG to enable a manager to know a priori what values are possible
> for a particular leaf somewhere, that's easy too -- if you see the addition
> of a new proprietary YANG module as a possibility.
>
> There are also ways to do similar things without hardcoding the value(s)
> in the YANG, e.g. in factory default data or controlled by licenses. The
> acceptable values would sit in a system controlled list (i.e. operator
> writes prevented by NACM).
>
> /jan
>
>
> type of an interface.  Assume that we have an interface stack defined and
> the lowest layer of the stack (the physical interface) is of type fastdsl.
>   In principle a NC client can send an edit-config to the server and change
> the type of that interface to something else.  It is still a valid YANG
> model but it does not make any
>
>
> If a client tries to set the type of an interface to a value that can
> never be used by the system, e.g., if the type is not supported or if the
> type does not match the name of the interface, the server MUST reject the
> request.
>
> [Bart Bogaert] Ok.  That is very clear but the NETCONF server can only
> reject if 1. there are rules in the YANG model that allow this, 2. An
> external application involved in the transaction tells the NC server in the
> box that this change is not allowed.  We are actually looking for a
> solution whereby the client, by using the device YANG model, can know (from
> YANG rules) that this change is not allowed.  For now I have not found such
> a solution to express this in YANG.  Having these kind of checks hidden
> from the client actually makes the device less programmable as the client
> needs to have a connection with the device.  For devices that are not
> always on and the client wants to accept changes on behalf of the device
> (which get forwarded when the device is powered up again) it would be good
> to have a great deal of certainty that the already accepted configuration
> by the client will also be accepted by the server.
>
>

---

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 30 Nov 2016 11:05:40 +0100

On 11/29/2016 05:18 PM, Jan Lindblad wrote:

> Bart,
>
> Jürgen et al are of course right in what they say, but if you really 
> want to use YANG to enable a manager to know a priori what values are 
> possible for a particular leaf somewhere, that's easy too -- if you 
> see the addition of a new proprietary YANG module as a possibility.
>
>     must 
> "not(/if:interfaces/if:interface[not(if:type='ianaift:fastdsl')])" {
+1. We use the same approach for defining device specific limitations in 
YANG.

---

From: Alex Campbell <[email-masked]>
Date: Wed, 30 Nov 2016 21:26:20 +0000

At Aviat we've been using deviations for this:

module aviat-ietf-interfaces-dev {
    // ...

    deviation "/if:interfaces/if:interface" {
        deviate add {
            must "if:type = 'ianaift:l2vlan' or if:type = 'ianaift:ethernetCsmacd'
                  or if:type = 'rl:radio-link-terminal' or if:type = 'rl:carrier-termination'
                  or if:type = 'ianaift:ieee8023adLag'";
        }
    }
}

________________________________________
From: netmod <[email-masked]> on behalf of Vladimir Vassilev <[email-masked]>
Sent: Wednesday, 30 November 2016 11:05 p.m.
To: Jan Lindblad; [email-masked]
Subject: Re: [netmod] How to prevent a client from modifying the type of an interface?

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Nov 2016 14:03:00 -0800

>                   or if:type = 'ianaift:ieee8023adLag'";
+1

This is the correct way to add constraints (already supported since YANG
1.0)

Andy