Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03

[Andy Bierman <[e-mail]>]

On Tue, Mar 22, 2016 at 2:30 PM, Tom Yu <[e-mail]> wrote:

> Andy Bierman <[e-mail]> writes:
>
> > The YANG library provides the same information that is currently
> > in the NETCONF <hello> message.
> >
> > It is expected that NACM (RFC 6536) will be used to prevent access
> > to sensitive operations, notifications, and data.
> > However NACM is optional-to-implement with NETCONF and RESTCONF.
> >
> > The risk is the same as current NETCONF.
> > If a specific module/revision implementation is known to
> > be vulernable, then NETCONF and this library both let
> > the client know it is running on the server.
>
> If the risk is the same as current NETCONF, then why mention it in this
> document?  It seems to me that the YANG library provides somewhat more
> detail than the NETCONF <hello> message, right?  The YANG library
> provides deviation and conformance details, unlike what I see in the
> NETCONF <hello> message description in RFC6241, unless there's something
> I'm missing.
>
>

The YANG library provides the revision date of the deviations module,
which is not included in the NETCONF <hello>.

It  also lists the submodules and their revisions, which is
not contained in the NETCONF <hello>.

The NETCONF <hello> message is not specified well enough to
make any other generalizations about the differences.





> It would be good to clarify whether the risks of exposing
> /modules-state/module include vulnerabilities in the NETCONF
> implementation itself, or with vulnerabilities in the associated
> underlying network device functionality for which NETCONF provides
> configuration access (perhaps both, to different degrees?).
>


The library is intended for other protocols such as RESTCONF.

Is there some specific text you want changed?
This is the only non-boilerplate text in the section:
Is there some part of this that is incorrect?



   o  /modules-state/module: The module list used in a server
      implementation may help an attacker identify the server
      capabilities and server implementations with known bugs.  Server
      vulnerabilities may be specific to particular modules, module
      revisions, module features, or even module deviations.  This
      information is included in each module entry.  For example, if a
      particular operation on a particular data node is known to cause a
      server to crash or significantly degrade device performance, then
      the module list information will help an attacker identify server
      implementations with such a defect, in order to launch a denial of
      service attack on the device.