Subject: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

From: Eric Rescorla <[email-masked]>
Date: Tue, 09 Oct 2018 20:10:51 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-netmod-schema-mount-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3506

DETAIL
S 4.
>   
>      It is worth emphasizing that the nodes specified in
>      "parent-reference" leaf-list are available in the mounted schema only
>      for XPath evaluations.  In particular, they cannot be accessed there
>      via network management protocols such as NETCONF [RFC6241] or
>      RESTCONF [RFC8040].

What are the security implications of this XPath reference outside the
mount jail? Specifically, how does it interact with the access control
for the enclosing module.

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Oct 2018 14:32:57 +0200 (CEST)

Hi,

> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/

There is no such interaction, since access control comes into play
when some external entity accesses the data through some management
protocol, and the nodes from the "parent-reference" expressions cannot
be accessed via management protocols.

The last sentence of the quoted paragraph was supposed to make this
clear, but it seems we might need some additional explanation?

/martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Oct 2018 06:33:27 -0700

On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund <[email-masked]> wrote:

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

Yes, I think so. I guess I'm not clear on what the XPath expressions are
for if they
can't be accessed via the management protocols. How can they be used?

-Ekr

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Oct 2018 15:38:31 +0200 (CEST)

> can't be accessed via the management protocols. How can they be used?

These are XPath expressions defined in the YANG models themselves,
such as "must" expressions or "leafrefs".   The description of
"parent-reference" refer to them as:

               [...] XPath
               expressions whose context nodes are defined in the
               mounted schema

/martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Oct 2018 09:29:35 -0700

I'm sorry but I don't understand this.

Does the externally visible behavior of any mounted module depend in any
way on these XPATH references

-Ekr

On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund <[email-masked]> wrote:

> > > > >      "parent-reference" leaf-list are available in the mounted
> schema
> > > only

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Oct 2018 09:18:17 +0200 (CEST)

> way on these XPATH references

Yes, but note that these XPath expressions ("parent-reference") are
read-only (config false in the YANG model).  Thus they are set by the
implementation, and used to inform the operator about the environment
in which other XPath expressions are evaluated.

/martin

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Oct 2018 05:37:09 -0700

That seems like it's going to have some pretty surprising consequences and
at minimum needs more information in the Security Considerations.

On Thu, Oct 11, 2018 at 12:18 AM Martin Bjorklund <[email-masked]> wrote:

> > > > > > email addresses included in the To and CC lines. (Feel free to
> cut
> > > this
> > > > > > >      for XPath evaluations.  In particular, they cannot be
> accessed
> > > > > there
> > > > > > What are the security implications of this XPath reference
> outside
> > > the

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 16 Oct 2018 14:45:45 +0200 (CEST)

Hi,

> at minimum needs more information in the Security Considerations.

Ok.  Howabout we add a paragraph to the end of the Security
Considerations section:

  Care must be taken when the "parent-reference" XPath expressions are
  constructed, since the result of the evaluation of these expressions
  is added to the accessible tree for any XPath expression found in
  the mounted schema.

/martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Oct 2018 06:00:18 -0700

I'm sorry, but I still don't think I understand the security impacts of
this well enough to know if this text is OK.

Can you provide a more detailed explanation of what XPath expressions can
and cannot do here? Happy to discuss live either on the phone or in BKK

-Ekr

On Tue, Oct 16, 2018 at 5:45 AM Martin Bjorklund <[email-masked]> wrote:

> > > > > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund <[email-masked]
> >
> > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > > When responding, please keep the subject line intact and
> reply
> > > to all
> > > > > > > > mount jail? Specifically, how does it interact with the
> access
> > > > > control
> > > > > > Yes, I think so. I guess I'm not clear on what the XPath
> expressions
> > > are
> > > > > > for if they

---

From: joel jaeggli <[email-masked]>
Date: Tue, 16 Oct 2018 09:05:50 -0700

On 10/16/18 06:00, Eric Rescorla wrote:
> Can you provide a more detailed explanation of what XPath expressions
> can and cannot do here? Happy to discuss live either on the phone or in BKK
I'm probably grossly simplifying the goal here, but.

xpath statement allow for referencing another path or applying
constraints e.g. when / must (rfc 6020)

the canonical example in 6020 being something like

  container interface {
      leaf ifType {
          type enumeration {
              enum ethernet;
              enum atm;
          }
      }
      leaf ifMTU {
          type uint32;
      }
      must "ifType != 'ethernet' or " +
           "(ifType = 'ethernet' and ifMTU = 1500)" {
          error-message "An ethernet MTU must be 1500";
      }
      must "ifType != 'atm' or " +
           "(ifType = 'atm' and ifMTU <= 17966 and ifMTU >= 64)" {
          error-message "An atm MTU must be  64 .. 17966";
      }

http://www.yang-central.org/twiki/pub/Main/YangDocuments/rfc6020.html#xpath

Imposing constraints using nodes in mounted modules is kind of a key
application of schema-mount.

> -Ekr
> 
> 
> On Tue, Oct 16, 2018 at 5:45 AM Martin Bjorklund <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
>     Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>     > On Thu, Oct 11, 2018 at 12:18 AM Martin Bjorklund <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > > Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>     > > > On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     > > >
>     > > > > Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>     > > > > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund
>     <[email-masked] <mailto:[email-masked]>>
>     > > wrote:
>     > > > > >
>     > > > > > > Hi,
>     > > > > > >
>     > > > > > > Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>     > > > > > > > When responding, please keep the subject line intact
>     and reply
>     > > to all
>     > > > > > > > The document, along with other ballot positions, can
>     be found
>     > > here:
>     > > > > > > >
>     > > > > > > > mount jail? Specifically, how does it interact with
>     the access
>     > > > > control
>     > > > > > > protocol, and the nodes from the "parent-reference"
>     expressions
>     > > cannot

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Oct 2018 14:51:41 -0700

OK, after reading your explanation and the example, I think I am clearer on
the use case and the text you propose seems appropriate. Why don't you
provide a new ID and I'll clear my DISCUSS

-Ekr

---

From: joel jaeggli <[email-masked]>
Date: Tue, 16 Oct 2018 14:54:07 -0700

On 10/16/18 14:51, Eric Rescorla wrote:
> OK, after reading your explanation and the example, I think I am clearer
> on the use case and the text you propose seems appropriate. Why don't
> you provide a new ID and I'll clear my DISCUSS

Thanks I think the authors will have that out shortly.

joel

> -Ekr
> 
> 
> On Tue, Oct 16, 2018 at 9:05 AM joel jaeggli <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     Hi,
>     >
>     >     Eric Rescorla <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >     > That seems like it's going to have some pretty surprising
>     >     consequences and
>     >     > at minimum needs more information in the Security
>     Considerations.
>     >
>     >     > On Thu, Oct 11, 2018 at 12:18 AM Martin Bjorklund
>     <[email-masked] <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >     >
>     >     > > Eric Rescorla <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >     > > > I'm sorry but I don't understand this.
>     >     > > >
>     >     > > > Does the externally visible behavior of any mounted module
>     >     depend in any
>     >     > > > way on these XPATH references
>     >     > >
>     >     > > Yes, but note that these XPath expressions
>     ("parent-reference") are
>     >     > > read-only (config false in the YANG model).  Thus they are set
>     >     by the
>     >     > > implementation, and used to inform the operator about the
>     >     environment
>     >     > > in which other XPath expressions are evaluated.
>     >     > >
>     >     > >
>     >     > > /martin
>     >     > >
>     >     > >
>     >     > > >
>     >     > > > -Ekr
>     >     > > >
>     >     > > >
>     >     > > >
>     >     > > >
>     >     > > > On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund
>     >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     >     > > >
>     >     > > > > Eric Rescorla <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >     > > > > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund
>     >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     >     > > wrote:
>     >     > > > > >
>     >     > > > > > > Hi,
>     >     > > > > > >
>     >     > > > > > > Eric Rescorla <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >     > > > > > > > Eric Rescorla has entered the following ballot
>     >     position for
>     >     > > > > > > > draft-ietf-netmod-schema-mount-11: Discuss
>     >     > > > > > > >
>     >     > > > > > > > When responding, please keep the subject line intact
>     >     and reply
>     >     > > to all
>     >     > > > > > > > email addresses included in the To and CC lines.
>     (Feel
>     >     free to
>     >     > > cut
>     >     > > > > this
>     >     > > > > > > > introductory paragraph, however.)
>     >     > > > > > > >
>     >     > > > > > > >
>     >     > > > > > > > Please refer to
>     >     > > > > > >
>     >     > > > > > > > for more information about IESG DISCUSS and COMMENT
>     >     positions.
>     >     > > > > > > >
>     >     > > > > > > >
>     >     > > > > > > > The document, along with other ballot positions, can
>     >     be found
>     >     > > here:
>     >     > > > > > > >
>     >     > > > > > > >
>     >     > > > > > > >
>     >     > > > > > > >
>     >     > > > > > > >
>     >     > > > >
>     >     > > > > > > > DISCUSS:
>     >     > > > > > > >
>     >     > > > >
>     >     > > > > > > >
>     >     > > > > > > > Rich version of this review at:
>     >     > > > > > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506
>     >     > > > > > > >
>     >     > > > > > > >
>     >     > > > > > > >
>     >     > > > > > > > DETAIL
>     >     > > > > > > > S 4.
>     >     > > > > > > > >
>     >     > > > > > > > >      It is worth emphasizing that the nodes
>     specified in
>     >     > > > > > > > >      "parent-reference" leaf-list are available in
>     >     the mounted
>     >     > > > > schema
>     >     > > > > > > only
>     >     > > > > > > > >      for XPath evaluations.  In particular, they
>     >     cannot be
>     >     > > accessed
>     >     > > > > > > there
>     >     > > > > > > > >      via network management protocols such as
>     NETCONF
>     >     > > [RFC6241] or
>     >     > > > > > > > >      RESTCONF [RFC8040].
>     >     > > > > > > >
>     >     > > > > > > > What are the security implications of this XPath
>     reference
>     >     > > outside
>     >     > > > > the
>     >     > > > > > > > mount jail? Specifically, how does it interact with
>     >     the access
>     >     > > > > control
>     >     > > > > > > > for the enclosing module.
>     >     > > > > > >
>     >     > > > > > > There is no such interaction, since access control
>     comes
>     >     into play
>     >     > > > > > > when some external entity accesses the data
>     through some
>     >     management
>     >     > > > > > > protocol, and the nodes from the "parent-reference"
>     >     expressions
>     >     > > cannot
>     >     > > > > > > be accessed via management protocols.
>     >     > > > > > >
>     >     > > > > > > The last sentence of the quoted paragraph was supposed
>     >     to make this
>     >     > > > > > > clear, but it seems we might need some additional
>     >     explanation?
>     >     > > > > > >
>     >     > > > > >
>     >     > > > > > Yes, I think so. I guess I'm not clear on what the XPath
>     >     expressions
>     >     > > are
>     >     > > > > > for if they
>     >     > > > > > can't be accessed via the management protocols. How can
>     >     they be used?
>     >     > > > >
>     >     > > > > These are XPath expressions defined in the YANG models
>     >     themselves,
>     >     > > > > such as "must" expressions or "leafrefs".   The
>     description of
>     >     > > > > "parent-reference" refer to them as:
>     >     > > > >
>     >     > > > >                [...] XPath
>     >     > > > >                expressions whose context nodes are defined
>     >     in the
>     >     > > > >                mounted schema
>     >     > > > >
>     >     > > > >
>     >     > > > >
>     >     > > > > /martin
>     >     > > > >
>     >     > >
>     >
> 
>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Oct 2018 09:24:51 +0200 (CEST)

Hi,

> provide a new ID and I'll clear my DISCUSS

Thank you!  I have fixed this and uploaded a new version
(draft-ietf-netmod-schema-mount-12).

/martin