Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7407

A YANG Data Model for SNMP Configuration

Pages: 88
Proposed Standard
Errata
Part 4 of 4 – Pages 71 to 88
First   Prev   None

Top   ToC   RFC7407 - Page 71   prevText

5. IANA Considerations

This document registers two URIs in the "IETF XML Registry" [RFC3688]. Following the format in RFC 3688, the following registrations have been made. URI: urn:ietf:params:xml:ns:yang:ietf-snmp Registrant Contact: The NETMOD WG of the IETF. XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name Registrant Contact: The NETMOD WG of the IETF. XML: N/A, the requested URI is an XML namespace. This document registers the following YANG modules in the "YANG Module Names" registry [RFC6020]. name: ietf-snmp namespace: urn:ietf:params:xml:ns:yang:ietf-snmp prefix: snmp reference: RFC 7407 name: ietf-x509-cert-to-name namespace: urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name prefix: x509c2n reference: RFC 7407 The document registers the following YANG submodules in the "YANG Module Names" registry [RFC6020]. name: ietf-snmp-common parent: ietf-snmp reference: RFC 7407 name: ietf-snmp-engine parent: ietf-snmp reference: RFC 7407
Top   ToC   RFC7407 - Page 72
        name:         ietf-snmp-community
        parent:       ietf-snmp
        reference:    RFC 7407

        name:         ietf-snmp-notification
        parent:       ietf-snmp
        reference:    RFC 7407

        name:         ietf-snmp-target
        parent:       ietf-snmp
        reference:    RFC 7407

        name:         ietf-snmp-vacm
        parent:       ietf-snmp
        reference:    RFC 7407

        name:         ietf-snmp-usm
        parent:       ietf-snmp
        reference:    RFC 7407

        name:         ietf-snmp-tsm
        parent:       ietf-snmp
        reference:    RFC 7407

        name:         ietf-snmp-tls
        parent:       ietf-snmp
        reference:    RFC 7407

        name:         ietf-snmp-ssh
        parent:       ietf-snmp
        reference:    RFC 7407

6. Security Considerations

The YANG module and submodules defined in this memo are designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer and the mandatory to implement secure transport is SSH [RFC6242]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF users to a pre-configured subset of all available NETCONF protocol operations and content. There are a number of data nodes defined in the YANG module and submodules which are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g.,
Top   ToC   RFC7407 - Page 73
   edit-config) to these data nodes without proper protection can have a
   negative effect on network operations.  These are the subtrees and
   data nodes and their sensitivity/vulnerability:

   o  The "/snmp/engine" subtree contains the configuration of general
      parameters of an SNMP engine such as the endpoints to listen on,
      the transports and SNMP versions enabled, or the engine's
      identity.  Write access to this subtree should only be granted to
      entities configuring general SNMP engine parameters.

   o  The "/snmp/target" subtree contains the configuration of SNMP
      targets and, in particular, which transports to use and their
      security parameters.  Write access to this subtree should only be
      granted to the security administrator and entities configuring
      SNMP notification forwarding behavior.

   o  The "/snmp/notify" and "/snmp/notify-filter-profile" subtrees
      contain the configuration for the SNMP notification forwarding and
      filtering mechanism.  Write access to these subtrees should only
      be granted to entities configuring SNMP notification forwarding
      behavior.

   o  The "/snmp/proxy" subtree contains the configuration for SNMP
      proxies.  Write access to this subtree should only be granted to
      entities configuring SNMP proxies.

   o  The "/snmp/community" subtree contains the configuration of the
      Community-based Security Model.  Write access to this subtree
      should only be granted to the security administrator.

   o  The "/snmp/usm" subtree contains the configuration of the User-
      based Security Model.  Write access to this subtree should only be
      granted to the security administrator.

   o  The "/snmp/tsm" subtree contains the configuration of the
      Transport Layer Security (TLS) Transport Model for SNMP.  Write
      access to this subtree should only be granted to the security
      administrator.

   o  The "/snmp/tlstm" subtree contains the configuration of the SNMP
      transport over (D)TLS and, in particular, the configuration of how
      certificates are mapped to SNMP security names.  Write access to
      this subtree should only be granted to the security administrator.

   o  The "/snmp/vacm" subtree contains the configuration of the View-
      based Access Control Model used by SNMP to authorize access to
      management information via SNMP.  Write access to this subtree
      should only be granted to the security administrator.
Top   ToC   RFC7407 - Page 74
   Some of the readable data nodes in the YANG module and submodules may
   be considered sensitive or vulnerable in some network environments.
   It is thus important to control read access (e.g., via get, get-
   config, or notification) to these data nodes.  These are the subtrees
   and data nodes and their sensitivity/vulnerability:

   o  The "/snmp/engine" subtree exposes general information about an
      SNMP engine such as which version(s) of SNMP are enabled or which
      transports are enabled.

   o  The "/snmp/target" subtree exposes information about which
      transports are used to reach certain SNMP targets and which
      transport-specific parameters are used.

   o  The "/snmp/notify" and "/snmp/notify-filter-profile" subtrees
      expose information about how notifications are filtered and
      forwarded to notification targets.

   o  The "/snmp/proxy" subtree exposes information about proxy
      relationships.

   o  The "/snmp/community", "/snmp/usm", "/snmp/tsm", "/snmp/tlstm",
      and "/snmp/vacm" subtrees are specifically sensitive since they
      expose information about the authentication and authorization
      policy used by an SNMP engine.

   Changes to the SNMP access control rules should be done in an atomic
   way (through a single edit-config or a single commit), or care must
   be taken that they are done in a sequence that does not temporarily
   open access to resources.  Implementations supporting SNMP write
   access must ensure that any SNMP access control rule changes over
   NETCONF are also atomic to the SNMP instrumentation.  In particular,
   changes involving an internal delete/create cycle (e.g., to move a
   user to a different group) must be done with sufficient protections
   such that even a power fail immediately after the delete does not
   leave the administrator locked out.

   Security administrators need to ensure that NETCONF access control
   rules and SNMP access control rules implement a consistent security
   policy.  Specifically, the SNMP access control rules should prevent
   accidental leakage of sensitive security parameters such as community
   strings.  See the Security Considerations section of [RFC3584] for
   further details.
Top   ToC   RFC7407 - Page 75

7. References

7.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>. [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, June 2011, <http://www.rfc-editor.org/info/rfc6242>. [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, March 2012, <http://www.rfc-editor.org/info/rfc6536>. [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, July 2013, <http://www.rfc-editor.org/info/rfc6991>.

7.2. Informative References

[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002, <http://www.rfc-editor.org/info/rfc3411>. [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002, <http://www.rfc-editor.org/info/rfc3412>. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002, <http://www.rfc-editor.org/info/rfc3413>. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002, <http://www.rfc-editor.org/info/rfc3414>.
Top   ToC   RFC7407 - Page 76
   [RFC3415]  Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
              Access Control Model (VACM) for the Simple Network
              Management Protocol (SNMP)", STD 62, RFC 3415, December
              2002, <http://www.rfc-editor.org/info/rfc3415>.

   [RFC3417]  Presuhn, R., "Transport Mappings for the Simple Network
              Management Protocol (SNMP)", STD 62, RFC 3417, December
              2002, <http://www.rfc-editor.org/info/rfc3417>.

   [RFC3418]  Presuhn, R., "Management Information Base (MIB) for the
              Simple Network Management Protocol (SNMP)", STD 62, RFC
              3418, December 2002,
              <http://www.rfc-editor.org/info/rfc3418>.

   [RFC3419]  Daniele, M. and J. Schoenwaelder, "Textual Conventions for
              Transport Addresses", RFC 3419, December 2002,
              <http://www.rfc-editor.org/info/rfc3419>.

   [RFC3584]  Frye, R., Levi, D., Routhier, S., and B. Wijnen,
              "Coexistence between Version 1, Version 2, and Version 3
              of the Internet-standard Network Management Framework",
              BCP 74, RFC 3584, August 2003,
              <http://www.rfc-editor.org/info/rfc3584>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004, <http://www.rfc-editor.org/info/rfc3688>.

   [RFC3826]  Blumenthal, U., Maino, F., and K. McCloghrie, "The
              Advanced Encryption Standard (AES) Cipher Algorithm in the
              SNMP User-based Security Model", RFC 3826, June 2004,
              <http://www.rfc-editor.org/info/rfc3826>.

   [RFC5591]  Harrington, D. and W. Hardaker, "Transport Security Model
              for the Simple Network Management Protocol (SNMP)", STD
              78, RFC 5591, June 2009,
              <http://www.rfc-editor.org/info/rfc5591>.

   [RFC5592]  Harrington, D., Salowey, J., and W. Hardaker, "Secure
              Shell Transport Model for the Simple Network Management
              Protocol (SNMP)", RFC 5592, June 2009,
              <http://www.rfc-editor.org/info/rfc5592>.

   [RFC6353]  Hardaker, W., "Transport Layer Security (TLS) Transport
              Model for the Simple Network Management Protocol (SNMP)",
              STD 78, RFC 6353, July 2011,
              <http://www.rfc-editor.org/info/rfc6353>.
Top   ToC   RFC7407 - Page 77
   [RFC6643]  Schoenwaelder, J., "Translation of Structure of Management
              Information Version 2 (SMIv2) MIB Modules to YANG
              Modules", RFC 6643, July 2012,
              <http://www.rfc-editor.org/info/rfc6643>.
Top   ToC   RFC7407 - Page 78

Appendix A. Example Configurations

A.1. Engine Configuration Example

Below is an XML instance document showing a configuration of an SNMP engine listening on UDP port 161 on IPv4 and IPv6 endpoints and accepting SNMPv2c and SNMPv3 messages. <snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp"> <engine> <enabled>true</enabled> <listen> <name>all-ipv4-udp</name> <udp> <ip>0.0.0.0</ip> <port>161</port> </udp> </listen> <listen> <name>all-ipv6-udp</name> <udp> <ip>::</ip> <port>161</port> </udp> </listen> <version> <v2c/> <v3/> </version> <engine-id>80:00:02:b8:04:61:62:63</engine-id> </engine> </snmp>

A.2. Community Configuration Example

Below is an XML instance document showing a configuration that maps the community name "public" to the security-name "community-public" on the local engine with the default context name. The target tag "community-public-access" filters the access to this community name. <snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp"> <community> <index>1</index> <text-name>public</text-name> <security-name>community-public</security-name> <target-tag>community-public-access</target-tag> </community> <target>
Top   ToC   RFC7407 - Page 79
       <name>management-station</name>
       <udp>
         <ip>2001:db8::abcd</ip>
         <port>161</port>
       </udp>
       <tag>blue</tag>
       <tag>community-public-access</tag>
       <target-params>v2c-public</target-params>
     </target>
     <target-params>
       <name>v2c-public</name>
       <v2c>
         <security-name>community-public</security-name>
       </v2c>
     </target-params>
   </snmp>

A.3. User-Based Security Model Configuration Example

Below is an XML instance document showing the configuration of a local user "joey" who has no authentication or privacy keys. For the remote SNMP engine identified by the snmpEngineID '800002b804616263'H, two users are configured. The user "matt" has a localized SHA authentication key, and the user "russ" has a localized SHA authentication key and an AES encryption key. <snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp"> <usm> <local> <user> <name>joey</name> </user> </local> <remote> <engine-id>00:00:00:00:00:00:00:00:00:00:00:02</engine-id> <user> <name>matt</name> <auth> <sha> <!-- The 'key' value is split into two lines to conform to the RFC formatting rules. --> <key>66:95:fe:bc:92:88:e3:62:82:23: 5f:c7:15:1f:12:84:97:b3:8f:3f</key> </sha> </auth> </user>
Top   ToC   RFC7407 - Page 80
         <user>
           <name>russ</name>
           <auth>
             <sha>
               <!--
                   The 'key' value is split into two lines to conform to
                   the RFC formatting rules.
               -->
               <key>66:95:fe:bc:92:88:e3:62:82:23:
                    5f:c7:15:1f:12:84:97:b3:8f:3f</key>
             </sha>
           </auth>
           <priv>
             <aes>
               <!--
                   The 'key' value is split into two lines to conform to
                   the RFC formatting rules.
               -->
               <key>66:95:fe:bc:92:88:e3:62:82:23:
                    5f:c7:15:1f:12:84</key>
             </aes>
           </priv>
         </user>
       </remote>
     </usm>
     <target>
       <name>bluebox</name>
       <udp>
         <ip>2001:db8::abcd</ip>
         <port>161</port>
       </udp>
       <tag>blue</tag>
       <target-params>matt-auth</target-params>
     </target>
     <target-params>
       <name>matt-auth</name>
       <usm>
         <user-name>matt</user-name>
         <security-level>auth-no-priv</security-level>
       </usm>
     </target-params>
   </snmp>
Top   ToC   RFC7407 - Page 81

A.4. Target and Notification Configuration Example

Below is an XML instance document showing the configuration of a notification generator application (see Appendix A of [RFC3413]). Note that the USM-specific objects are defined in the "ietf-snmp-usm" submodule. <snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp"> <target> <name>addr1</name> <udp> <ip>192.0.2.3</ip> <port>162</port> </udp> <tag>group1</tag> <target-params>joe-auth</target-params> </target> <target> <name>addr2</name> <udp> <ip>192.0.2.6</ip> <port>162</port> </udp> <tag>group1</tag> <target-params>joe-auth</target-params> </target> <target> <name>addr3</name> <udp> <ip>192.0.2.9</ip> <port>162</port> </udp> <tag>group2</tag> <target-params>bob-priv</target-params> </target> <target-params> <name>joe-auth</name> <usm> <user-name>joe</user-name> <security-level>auth-no-priv</security-level> </usm> </target-params> <target-params> <name>bob-priv</name> <usm> <user-name>bob</user-name> <security-level>auth-priv</security-level> </usm>
Top   ToC   RFC7407 - Page 82
     </target-params>
     <notify>
       <name>group1</name>
       <tag>group1</tag>
       <type>trap</type>
     </notify>
     <notify>
       <name>group2</name>
       <tag>group2</tag>
       <type>trap</type>
     </notify>
   </snmp>

A.5. Proxy Configuration Example

Below is an XML instance document showing the configuration of a proxy forwarder application. It proxies SNMPv2c messages from command generators to a file server running an SNMPv1 agent that recognizes two community strings, "private" and "public", with different associated read views. The file server is represented as two "target" instances, one for each community string. If the proxy receives an SNMPv2c message with the community string "public" from a device in the "Office Network" or "Home Office Network", it gets tagged as "trusted", and the proxy uses the "private" community string when sending the message to the file server. Other SNMPv2c messages with the community string "public" get tagged as "non-trusted", and the proxy uses the "public" community string for these messages. There is also a special "backdoor" community string that can be used from any location to get "trusted" access. The "Office Network" and "Home Office Network" are represented as two "target" instances. These "target" instances have target-params "none", which refers to a non-existing target-params entry. <snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp"> <target> <name>File Server (private)</name> <udp> <ip>192.0.2.1</ip> </udp> <target-params>v1-private</target-params> </target> <target> <name>File Server (public)</name> <udp> <ip>192.0.2.1</ip>
Top   ToC   RFC7407 - Page 83
       </udp>
       <target-params>v1-public</target-params>
     </target>
     <target>
       <name>Office Network</name>
       <udp>
         <ip>192.0.2.0</ip>
         <prefix-length>24</prefix-length>
       </udp>
       <tag>office</tag>
       <target-params>none</target-params>
     </target>
     <target>
       <name>Home Office Network</name>
       <udp>
         <ip>203.0.113.0</ip>
         <prefix-length>24</prefix-length>
       </udp>
       <tag>home-office</tag>
       <target-params>none</target-params>
     </target>
     <target-params>
       <name>v1-private</name>
       <v1>
         <security-name>private</security-name>
       </v1>
     </target-params>
     <target-params>
       <name>v1-public</name>
       <v1>
         <security-name>public</security-name>
       </v1>
     </target-params>
     <target-params>
       <name>v2c-public</name>
       <v2c>
         <security-name>public</security-name>
       </v2c>
     </target-params>

     <!--
         Communities c1, c2, c3, and c4 are used for incoming messages
         that should be forwarded.

         Communities c3 and c5 are used for outgoing messages to the
         file server.
     -->
     <community>
Top   ToC   RFC7407 - Page 84
       <index>c1</index>
       <security-name>public</security-name>
       <engine-id>80:00:61:81:c8</engine-id>
       <context>trusted</context>
       <target-tag>office</target-tag>
     </community>
     <community>
       <index>c2</index>
       <security-name>public</security-name>
       <engine-id>80:00:61:81:c8</engine-id>
       <context>trusted</context>
       <target-tag>home-office</target-tag>
     </community>
     <community>
       <index>c3</index>
       <security-name>public</security-name>
       <engine-id>80:00:61:81:c8</engine-id>
       <context>not-trusted</context>
     </community>
     <community>
       <index>c4</index>
       <text-name>backdoor</text-name>
       <security-name>public</security-name>
       <engine-id>80:00:61:81:c8</engine-id>
       <context>trusted</context>
     </community>
     <community>
       <index>c5</index>
       <security-name>private</security-name>
       <engine-id>80:00:61:81:c8</engine-id>
       <context>trusted</context>
     </community>

     <proxy>
       <name>p1</name>
       <type>read</type>
       <context-engine-id>80:00:61:81:c8</context-engine-id>
       <context-name>trusted</context-name>
       <target-params-in>v2c-public</target-params-in>
       <single-target-out>File Server (private)</single-target-out>
     </proxy>
     <proxy>
       <name>p2</name>
       <type>read</type>
       <context-engine-id>80:00:61:81:c8</context-engine-id>
       <context-name>not-trusted</context-name>
       <target-params-in>v2c-public</target-params-in>
       <single-target-out>File Server (public)</single-target-out>
Top   ToC   RFC7407 - Page 85
     </proxy>
   </snmp>

   If an SNMPv2c Get request with community string "public" is received
   from an IP address tagged as "office" or "home-office", or if the
   request is received from anywhere else with community string
   "backdoor", the implied context is "trusted" so proxy entry "p1"
   matches.  The request is forwarded to the file server as SNMPv1 with
   community "private" using community table entry "c5" for outbound
   params lookup.

   If an SNMPv2c Get request with community string "public" is received
   from any other IP address, the implied context is "not-trusted" so
   proxy entry "p2" matches, and the request is forwarded to the file
   server as SNMPv1 with community "public".

A.6. View-Based Access Control Model Configuration Example

Below is an XML instance document showing the minimum-secure VACM configuration (see Appendix A of [RFC3415]). <snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp"> <vacm> <group> <name>initial</name> <member> <security-name>initial</security-name> <security-model>usm</security-model> </member> <access> <context></context> <security-model>usm</security-model> <security-level>no-auth-no-priv</security-level> <read-view>restricted</read-view> <notify-view>restricted</notify-view> </access> <access> <context></context> <security-model>usm</security-model> <security-level>auth-no-priv</security-level> <read-view>internet</read-view> <write-view>internet</write-view> <notify-view>internet</notify-view> </access> </group> <view> <name>initial</name> <include>1.3.6.1</include>
Top   ToC   RFC7407 - Page 86
       </view>
       <view>
         <name>restricted</name>
         <include>1.3.6.1</include>
       </view>
     </vacm>
   </snmp>

   The following XML instance document shows the semi-secure VACM
   configuration (only the view configuration is different).

   <snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp">
     <vacm>
       <group>
         <name>initial</name>
         <member>
           <security-name>initial</security-name>
           <security-model>usm</security-model>
         </member>
         <access>
           <context></context>
           <security-model>usm</security-model>
           <security-level>no-auth-no-priv</security-level>
           <read-view>restricted</read-view>
           <notify-view>restricted</notify-view>
         </access>
         <access>
           <context></context>
           <security-model>usm</security-model>
           <security-level>auth-no-priv</security-level>
           <read-view>internet</read-view>
           <write-view>internet</write-view>
           <notify-view>internet</notify-view>
         </access>
       </group>
       <view>
         <name>initial</name>
         <include>1.3.6.1</include>
       </view>
       <view>
         <name>restricted</name>
         <include>1.3.6.1.2.1.1</include>
         <include>1.3.6.1.2.1.11</include>
         <include>1.3.6.1.6.3.10.2.1</include>
         <include>1.3.6.1.6.3.11.2.1</include>
         <include>1.3.6.1.6.3.15.1.1</include>
       </view>
     </vacm>
Top   ToC   RFC7407 - Page 87
   </snmp>

A.7. Transport Layer Security Transport Model Configuration Example

Below is an XML instance document showing the configuration of the mapping of certificate to security name (see Appendices A.2 and A.3 of [RFC6353]). <snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp" xmlns:x509c2n= "urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name"> <tlstm> <cert-to-name> <id>1</id> <fingerprint>11:0A:05:11:00</fingerprint> <map-type>x509c2n:san-any</map-type> </cert-to-name> <cert-to-name> <id>2</id> <fingerprint>11:0A:05:11:00</fingerprint> <map-type>x509c2n:specified</map-type> <name> Joe Cool </name> </cert-to-name> </tlstm> </snmp>
Top   ToC   RFC7407 - Page 88

Acknowledgments

The authors want to thank Wes Hardaker and David Spakes for their detailed reviews. Additional valuable comments were provided by David Harrington, Borislav Lukovic, and Randy Presuhn. Juergen Schoenwaelder was partly funded by Flamingo, a Network of Excellence project (ICT-318488) supported by the European Commission under its Seventh Framework Programme.

Authors' Addresses

Martin Bjorklund Tail-f Systems EMail: mbj@tail-f.com Juergen Schoenwaelder Jacobs University EMail: j.schoenwaelder@jacobs-university.de