RFC 7856

Softwire Mesh Management Information Base (MIB)

📅 published May 2016, from ietf

Softwire Mesh Management Information Base (MIB) 🦋

Okay bestie, here's the header rundown ✨. This is RFC 7856, published in May 2016, and it's on the Standards Track (the real-deal, official-spec kind 💅). It's from the IETF, and the authors are Y. Cui, J. Dong, P. Wu, and M. Xu from Tsinghua University, plus A. Yla-Jaaski from Aalto University. Its ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so there's nothing to chase there 🌸.

Abstract 🌈

Okay so, this memo defines a chunk of the Management Information Base (MIB) that network management protocols in the Internet community can use 💖. Specifically, it defines the objects you need to manage a softwire mesh 🧚.

Status of This Memo 📜

This is an Internet Standards Track document, so it's official 🔥.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 📚.

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7856 🎀.

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved 🔒.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the date of publication. Please actually read these, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License ⚠️.

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  The Internet-Standard Management Framework  . . . . . . . . .   2
3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
4.  Structure of the MIB Module . . . . . . . . . . . . . . . . .   3
  4.1.  The swmSupportedTunnelTable Subtree . . . . . . . . . . .   3
  4.2.  The swmEncapsTable Subtree  . . . . . . . . . . . . . . .   3
  4.3.  The swmBGPNeighborTable Subtree . . . . . . . . . . . . .   4
  4.4.  The swmConformance Subtree  . . . . . . . . . . . . . . .   4
5.  Relationship to Other MIB Modules . . . . . . . . . . . . . .   4
  5.1.  Relationship to the IF-MIB  . . . . . . . . . . . . . . .   4
  5.2.  Relationship to the IP Tunnel MIB . . . . . . . . . . . .   5
  5.3.  MIB Modules Required for IMPORTS  . . . . . . . . . . . .   5
6.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   6
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
  9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  17
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1. Introduction 🧚

Okay so the softwire mesh framework [RFC5565] is a tunneling mechanism that lets islands of IPv4 networks talk to each other across a single IPv6 backbone, and the other way around too 🌍. In a softwire mesh, extended Multiprotocol BGP (MP-BGP) is what sets up the tunnels and advertises prefixes between Address Family Border Routers (AFBRs) 💖.

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, it defines objects for managing a softwire mesh [RFC5565] ✨.

2. The Internet-Standard Management Framework 📚

If you want a deep dive on the documents behind the current Internet-Standard Management Framework, check out section 7 of RFC 3410 [RFC3410] 🤓.

Managed objects are accessed through a virtual information store called the Management Information Base, or MIB 🗄️. MIB objects are usually accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580] 💅.

3. Terminology 💜

This document uses terminology from the softwire problem statement [RFC4925], the BGP encapsulation Subsequent Address Family Identifier (SAFI), the BGP tunnel encapsulation attribute [RFC5512], the softwire mesh framework [RFC5565], and the BGP IPsec tunnel encapsulation attribute [RFC5566] 🎀.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🫶.

4. Structure of the MIB Module 🍓

The Softwire Mesh MIB gives you a way to monitor the softwire mesh objects through SNMP 👀.

4.1. The swmSupportedTunnelTable Subtree 🦋

The swmSupportedTunnelTable subtree tells you which types of tunnels can be used for softwire mesh scenarios in the AFBR 🌸. The softwire mesh framework [RFC5565] does not mandate any particular tunneling technology. Based on the BGP tunnel encapsulation attribute tunnel types introduced by RFC 5512 [RFC5512] and RFC 5566 [RFC5566], the softwire mesh tunnel types include at least L2TPv3 (Layer 2 Tunneling Protocol version 3) over IP, GRE (Generic Routing Encapsulation), Transmit tunnel endpoint, IPsec in Tunnel-mode, IP in IP tunnel with IPsec Transport Mode, MPLS-in-IP tunnel with IPsec Transport Mode, and IP in IP 🌈.

The detailed encapsulation information for each tunnel type (for example, the L2TPv3 Session ID or the GRE Key) is not managed in the Softwire Mesh MIB 🙈.

4.2. The swmEncapsTable Subtree 🍓

The swmEncapsTable subtree holds the softwire mesh NLRI-NH information (Network Layer Reachability Information - Next Hop) about the AFBR 💖. It keeps the mapping between the External-IP (E-IP) prefix and the Internal-IP (I-IP) address of the next hop. These mappings decide which I-IP destination address gets used to encapsulate a received packet, based on its E-IP destination address ✨. The definitions of E-IP and I-IP are explained in Section 4.1 of RFC 5565 [RFC5565]. The number of entries in swmEncapsTable tells you how many softwire mesh tunnels are maintained in this AFBR 🔥.

4.3. The swmBGPNeighborTable Subtree 🧚

This subtree gives you the softwire mesh BGP neighbor information for an AFBR 🤝. It includes the address of the softwire mesh BGP peer and the kind of tunnel the AFBR would use to talk to that BGP peer 🎀.

4.4. The swmConformance Subtree 👑

This subtree provides the conformance information for MIB objects 📋.

5. Relationship to Other MIB Modules 🌸

5.1. Relationship to the IF-MIB 🦋

The Interfaces MIB [RFC2863] defines generic managed objects for managing interfaces. Each logical interface (physical or virtual) has an ifEntry. Tunnels are handled by creating logical interfaces (ifEntry). Since a softwire mesh interface is a tunnel, it has an entry in the Interface MIB and also an entry in the IP Tunnel MIB. Those corresponding entries are indexed by ifIndex 💜.

The ifOperStatus in the ifTable shows whether the mesh function of the AFBR has been triggered. If the softwire mesh capability is negotiated during the BGP OPEN phase, the mesh function is considered to be started and ifOperStatus is "up". Otherwise, ifOperStatus is "down" 🚦.

For an IPv4-over-IPv6 softwire mesh tunnel, ifInUcastPkts counts the number of IPv6 packets sent to the virtual interface for decapsulation into IPv4. ifOutUcastPkts counts the number of IPv6 packets generated by encapsulating IPv4 packets sent to the virtual interface. If those IPv4 packets need fragmentation, ifOutUcastPkts counts the packets after fragmentation 📦.

For an IPv6-over-IPv4 softwire mesh tunnel, ifInUcastPkts counts the number of IPv4 packets delivered to the virtual interface for decapsulation into IPv6. ifOutUcastPkts counts the number of IPv4 packets generated by encapsulating IPv6 packets sent down to the virtual interface. If those IPv6 packets need to be fragmented, ifOutUcastPkts counts the packets after fragmentation. Similar definitions apply to other counter objects in the ifTable 🧮.

5.2. Relationship to the IP Tunnel MIB 🌈

The IP Tunnel MIB [RFC4087] contains objects that apply to all IP tunnels, including softwire mesh tunnels. Meanwhile, the Softwire Mesh MIB extends the IP Tunnel MIB to describe encapsulation-specific information further 💖.

When running a point-to-multipoint tunnel, a softwire mesh AFBR needs to maintain an encapsulation table so it can do correct "forwarding" among AFBRs. This forwarding function on an AFBR works by using the E-IP destination address to look up the I-IP encapsulation destination address in the encapsulation table. An AFBR also needs to know the BGP peer information of the other AFBRs, so it can negotiate the NLRI-NH information and the tunnel parameters with them 🤝.

The Softwire Mesh MIB requires the implementation of the IP Tunnel MIB. The tunnelIfEncapsMethod in the tunnelIfEntry MUST be set to softwireMesh(16), and a corresponding entry in the Softwire Mesh MIB module will be presented for the tunnelIfEntry. The tunnelIfRemoteInetAddress MUST be set to "0.0.0.0" for IPv4 or "::" for IPv6, because it is a point-to-multipoint tunnel 🚨.

The tunnelIfAddressType in the tunnelIfTable represents the type of address in the corresponding tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress objects. tunnelIfAddressType is identical to swmEncapsIIPDstType in softwire mesh, which can support either IPv4-over-IPv6 or IPv6-over-IPv4. When swmEncapsEIPDstType is IPv6 and swmEncapsIIPDstType is IPv4, the tunnel type is IPv6-over-IPv4. When swmEncapsEIPDstType is IPv4 and swmEncapsIIPDstType is IPv6, the encapsulation mode is IPv4-over-IPv6 🎀.

5.3. MIB Modules Required for IMPORTS 📥

The following MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], SNMPv2-CONF [RFC2580], IF-MIB [RFC2863], and INET-ADDRESS-MIB [RFC4001] 💜.

6. Definitions 📖

SOFTWIRE-MESH-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, mib-2 FROM SNMPv2-SMI

    OBJECT-GROUP, MODULE-COMPLIANCE             FROM SNMPv2-CONF

    InetAddress, InetAddressType, InetAddressPrefixLength

    FROM INET-ADDRESS-MIB

    ifIndex                                FROM IF-MIB

    IANAtunnelType                         FROM IANAifType-MIB;

    swmMIB MODULE-IDENTITY
    LAST-UPDATED "201605110000Z"        -- May 11, 2016
    ORGANIZATION "Softwire Working Group"
    CONTACT-INFO
             "Yong Cui
              Email:  yong@csnet1.cs.tsinghua.edu.cn

              Jiang Dong
              Email:  knight.dongjiang@gmail.com

Part 1 wraps up right there, and Part 2 picks up from the MIB definitions 🧚💖

Okay, the MIB module keeps going and it is SO organized 🎀 Everything below is the actual machine-readable definition, so it stays exactly as written, DESCRIPTION strings included, because those are part of the module itself 💅

                 Peng Wu
                 Email:  weapon9@gmail.com

                 Mingwei Xu
                 Email:  xmw@cernet.edu.cn

                 Antti Yla-Jaaski
                 Email:  antti.yla-jaaski@aalto.fi

                 Email comments directly to the Softwire WG Mailing
                 List at softwires@ietf.org
                "
       DESCRIPTION
              "This MIB module contains managed object definitions for
               the softwire mesh framework.

               Copyright (c) 2016 IETF Trust and the persons
               identified as authors of the code.  All rights reserved.

               Redistribution and use in source and binary forms, with
               or without modification, is permitted pursuant to, and
               subject to the license terms contained in, the Simplified
               BSD License set forth in Section 4.c of the IETF Trust's
               Legal Provisions Relating to IETF Documents
               (http://trustee.ietf.org/license-info)."
       REVISION    "201605110000Z"
       DESCRIPTION "Initial version, published as RFC 7856"
       ::= { mib-2 239 }

   swmObjects OBJECT IDENTIFIER ::= { swmMIB 1 }

   -- swmSupportedTunnelTable
   swmSupportedTunnelTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SwmSupportedTunnelEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A table of objects that show what kinds of tunnels
           can be supported by the AFBR."
       ::= { swmObjects 1 }

   swmSupportedTunnelEntry  OBJECT-TYPE
       SYNTAX      SwmSupportedTunnelEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A set of objects that show what kinds of tunnels
           can be supported in the AFBR.  If the AFBR supports
           multiple tunnel types, the swmSupportedTunnelTable
           would have several entries."
       INDEX { swmSupportedTunnelType }
       ::= { swmSupportedTunnelTable 1 }

   SwmSupportedTunnelEntry ::= SEQUENCE {
       swmSupportedTunnelType              IANAtunnelType
   }

   swmSupportedTunnelType OBJECT-TYPE
       SYNTAX      IANAtunnelType
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Represents the tunnel type that can be used for softwire
           mesh scenarios, such as L2TPv3 over IP, GRE, Transmit
           tunnel endpoint, IPsec in Tunnel-mode, IP in IP tunnel with
           IPsec Transport Mode, MPLS-in-IP tunnel with IPsec Transport
           Mode, and IP in IP.  There is no restriction on the tunnel
           type the softwire mesh can use."
        REFERENCE

           "L2TPv3 over IP, GRE, and IP in IP in RFC 5512.
           Transmit tunnel endpoint, IPsec in Tunnel-mode, IP in IP
           tunnel with IPsec Transport Mode, MPLS-in-IP tunnel with
           IPsec Transport Mode in RFC 5566."
       ::= { swmSupportedTunnelEntry 1 }

   -- end of swmSupportedTunnelTable

   --swmEncapsTable
   swmEncapsTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SwmEncapsEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A table of objects that display the
           softwire mesh encapsulation information."
       ::= { swmObjects 2 }

   swmEncapsEntry  OBJECT-TYPE
       SYNTAX      SwmEncapsEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A table of objects that manage the softwire mesh I-IP
            encapsulation destination based on the E-IP destination
            prefix."
       INDEX { ifIndex,
               swmEncapsEIPDstType,
               swmEncapsEIPDst,
               swmEncapsEIPPrefixLength
             }
       ::= { swmEncapsTable 1 }

   SwmEncapsEntry ::=      SEQUENCE {
       swmEncapsEIPDstType       InetAddressType,
       swmEncapsEIPDst           InetAddress,
       swmEncapsEIPPrefixLength  InetAddressPrefixLength,
       swmEncapsIIPDstType       InetAddressType,
       swmEncapsIIPDst           InetAddress
   }

   swmEncapsEIPDstType OBJECT-TYPE
       SYNTAX      InetAddressType
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This object specifies the address type used for
           swmEncapsEIPDst.  It is different from the
           tunnelIfAddressType in the tunnelIfTable.  The
           swmEncapsEIPDstType is IPv6 (2) if it is IPv6-over-IPv4
           tunneling.  The swmEncapsEIPDstType is
           IPv4 (1) if it is IPv4-over-IPv6 tunneling."
       REFERENCE
           "IPv4 and IPv6 in RFC 4001."
       ::= { swmEncapsEntry 1 }

   swmEncapsEIPDst OBJECT-TYPE
       SYNTAX      InetAddress
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The E-IP destination prefix, which is
           used for I-IP encapsulation destination looking up.
           The type of this address is determined by the
           value of swmEncapsEIPDstType"
       REFERENCE
           "E-IP and I-IP in RFC 5565."
       ::= { swmEncapsEntry 2 }

   swmEncapsEIPPrefixLength OBJECT-TYPE
       SYNTAX      InetAddressPrefixLength
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The prefix length of the E-IP destination prefix."
       ::= { swmEncapsEntry 3 }

   swmEncapsIIPDstType OBJECT-TYPE
       SYNTAX      InetAddressType
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object specifies the address type used for
            swmEncapsIIPDst.  It is the same as the tunnelIfAddressType
            in the tunnelIfTable."
       REFERENCE
           "IPv4 and IPv6 in RFC 4001."
       ::= { swmEncapsEntry 4 }

   swmEncapsIIPDst OBJECT-TYPE
       SYNTAX      InetAddress
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The I-IP destination address, which is used as the
           encapsulation destination for the corresponding E-IP
           prefix.  Since the tunnelIfRemoteInetAddress in the
           tunnelIfTable should be 0.0.0.0 or ::, swmEncapIIPDst
           should be the destination address used in the outer
           IP header."
       REFERENCE
           "E-IP and I-IP in RFC 5565."
       ::= { swmEncapsEntry 5 }
   -- End of swmEncapsTable

   -- swmBGPNeighborTable
   swmBGPNeighborTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SwmBGPNeighborEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A table of objects that display the softwire mesh
           BGP neighbor information."
       ::= { swmObjects 3 }

   swmBGPNeighborEntry  OBJECT-TYPE
       SYNTAX      SwmBGPNeighborEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A set of objects that display the softwire mesh
           BGP neighbor information."
       INDEX {
               ifIndex,
               swmBGPNeighborInetAddressType,
               swmBGPNeighborInetAddress
             }
       ::= { swmBGPNeighborTable 1 }

   SwmBGPNeighborEntry ::= SEQUENCE {
           swmBGPNeighborInetAddressType    InetAddressType,
           swmBGPNeighborInetAddress        InetAddress,
           swmBGPNeighborTunnelType         IANAtunnelType
   }

   swmBGPNeighborInetAddressType OBJECT-TYPE
       SYNTAX      InetAddressType
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This object specifies the address type used for
            swmBGPNeighborInetAddress."
       ::= { swmBGPNeighborEntry 1 }

   swmBGPNeighborInetAddress OBJECT-TYPE
       SYNTAX      InetAddress
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The address of the AFBR's BGP neighbor.  The
           address type is the same as the tunnelIfAddressType
           in the tunnelIfTable."
       ::= { swmBGPNeighborEntry 2 }

   swmBGPNeighborTunnelType OBJECT-TYPE
       SYNTAX      IANAtunnelType
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Represents the type of tunnel that the AFBR
           chooses to transmit traffic with another AFBR/BGP
           neighbor."
       ::= { swmBGPNeighborEntry 3 }
   -- End of swmBGPNeighborTable


   -- conformance information
   swmConformance
                       OBJECT IDENTIFIER ::= { swmMIB 2 }
   swmCompliances
                       OBJECT IDENTIFIER ::= { swmConformance 1 }
   swmGroups
                       OBJECT IDENTIFIER ::= { swmConformance 2 }

    -- compliance statements
   swmCompliance MODULE-COMPLIANCE
      STATUS current
      DESCRIPTION
          "Describes the requirements for conformance to the Softwire
          Mesh MIB.

          The following index objects cannot be added as OBJECT
          clauses but nevertheless have compliance requirements:
          "
          -- OBJECT  swmEncapsEIPDstType
          -- SYNTAX  InetAddressType { ipv4(1), ipv6(2) }
          -- DESCRIPTION
          -- "An implementation is required to support
          --  global IPv4 and/or IPv6 addresses, depending
          --  on its support for IPv4 and IPv6."

          -- OBJECT  swmEncapsEIPDst
          -- SYNTAX  InetAddress (SIZE(4|16))
          -- DESCRIPTION
          -- "An implementation is required to support
          --  global IPv4 and/or IPv6 addresses, depending
          --  on its support for IPv4 and IPv6."

          -- OBJECT  swmEncapsEIPPrefixLength
          -- SYNTAX  InetAddressPrefixLength (Unsigned32 (0..128))
          -- DESCRIPTION
          -- "An implementation is required to support
          --  global IPv4 and/or IPv6 addresses, depending
          --  on its support for IPv4 and IPv6."

          -- OBJECT  swmBGPNeighborInetAddressType
          -- SYNTAX  InetAddressType { ipv4(1), ipv6(2) }
          -- DESCRIPTION
          -- "An implementation is required to support
          --  global IPv4 and/or IPv6 addresses, depending
          --  on its support for IPv4 and IPv6."

          -- OBJECT  swmBGPNeighborInetAddress
          -- SYNTAX  InetAddress (SIZE(4|16))
          -- DESCRIPTION
          -- "An implementation is required to support
          --  global IPv4 and/or IPv6 addresses, depending
          --  on its support for IPv4 and IPv6."

      MODULE -- this module
      MANDATORY-GROUPS    {
                            swmSupportedTunnelGroup,
                            swmEncapsGroup,
                            swmBGPNeighborGroup
                          }
      ::= { swmCompliances 1 }

   swmSupportedTunnelGroup    OBJECT-GROUP
      OBJECTS {
          swmSupportedTunnelType
      }
      STATUS  current
      DESCRIPTION
          "The collection of objects that are used to show
          what kind of tunnel the AFBR supports."
      ::= { swmGroups 1 }

   swmEncapsGroup    OBJECT-GROUP
      OBJECTS {
           swmEncapsIIPDst,
           swmEncapsIIPDstType
      }
      STATUS  current
      DESCRIPTION
          "The collection of objects that are used to display
          softwire mesh encapsulation information."
      ::= { swmGroups 2 }

   swmBGPNeighborGroup    OBJECT-GROUP
      OBJECTS {
           swmBGPNeighborTunnelType
      }
      STATUS  current
      DESCRIPTION
          "The collection of objects that are used to display
           softwire mesh BGP neighbor information."
      ::= { swmGroups 3 }

   END

The big thing to notice here is the INDEX clauses 👑 swmEncapsTable is indexed by ifIndex plus swmEncapsEIPDstType, swmEncapsEIPDst and swmEncapsEIPPrefixLength, and swmBGPNeighborTable is indexed by ifIndex plus swmBGPNeighborInetAddressType and swmBGPNeighborInetAddress. Main character energy 🦋

The conformance part is very structured 🌸 swmCompliance lists three MANDATORY-GROUPS, which are swmSupportedTunnelGroup, swmEncapsGroup and swmBGPNeighborGroup. The commented-out OBJECT clauses are kept as they are in the module, because the text says those index objects cannot be added as OBJECT clauses but still have compliance requirements 💀

7. Security Considerations 🔐✨

okay bestie, security is where we get serious 😤 this MIB reuses the IP Tunnel MIB, so the security considerations of the IP Tunnel MIB apply to the Softwire Mesh MIB too 🎀

there are no management objects in this MIB module with a MAX-ACCESS of read-write or read-create 🙅‍♀️ so if it's implemented correctly, there's no risk that an intruder can alter or create any of its management objects with direct SNMP SET operations. that's giving fortress energy 🏰💅

some of the readable objects (anything with a MAX-ACCESS other than not-accessible) might be sensitive or vulnerable depending on the network 👀 so it's important to control even GET and/or NOTIFY access to them, and maybe even encrypt their values when they travel over the network via SNMP 🔒 these are the objects and why they matter:

  • swmSupportedTunnelType, swmEncapsIIPDstType, swmEncapsIIPDst, and swmBGPNeighborTunnelType can expose the types of tunnels used inside the internal network 🫣
  • they could also potentially reveal the topology of the internal network 🗺️ which is so not the vibe for a hacker to know

SNMP versions before SNMPv3 did not include adequate security 💀 even if the network itself is secure (for example by using IPsec), there's no control over who on that secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module 😭

Implementations SHOULD provide the security features described by the SNMPv3 framework (see [RFC3410]) 🛡️ and implementations claiming compliance with the SNMPv3 standard MUST include full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826] 🔥 that part is non-negotiable, periodt 💅

Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353] 🦋

further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED 🙅‍♀️ instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security 🔐 it is then a customer/operator responsibility to make sure the SNMP entity giving access to an instance of this MIB module is properly configured, so the objects are only accessible to the principals (users) who legitimately have rights to GET or SET (change/create/delete) them 🫶

8. IANA Considerations 🧚

IANA has allocated the following OBJECT IDENTIFIER value and recorded it in the SMI Numbers registry, in the subregistry called "SMI Network Management MGMT Codes Internet-standard MIB" under the mib-2 branch (1.3.6.1.2.1) 🍓

        Descriptor        OBJECT IDENTIFIER value
        ----------        -----------------------
        swmMIB            { mib-2 239 }

IANA has also recorded the following IANAtunnelType Textual Convention within the IANAifType-MIB 🌈

        IANAtunnelType ::= TEXTUAL-CONVENTION
              SYNTAX     INTEGER {
                         softwireMesh(16)  -- softwire mesh tunnel
                         }

9. References 📚

9.1. Normative References

9.2. Informative References

Acknowledgements 🫶

The authors would like to thank Dave Thaler, Jean-Philippe Dionne, Qi Sun, Sheng Jiang, and Yu Fu for their valuable comments 💖

Authors' Addresses 💌

Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing  100084
China

Phone: +86-10-6260-3059
Email: yong@csnet1.cs.tsinghua.edu.cn


Jiang Dong
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing  100084
China

Phone: +86-10-6278-5822
Email: knight.dongjiang@gmail.com


Peng Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing  100084
China

Phone: +86-10-6278-5822
Email: weapon9@gmail.com


Mingwei Xu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing  100084
China

Phone: +86-10-6278-5822
Email: xmw@cernet.edu.cn

Antti Yla-Jaaski
Aalto University
Konemiehentie 2
Espoo  02150
Finland

Phone: +358-40-5954222
Email: antti.yla-jaaski@aalto.fi
📦 where this page comes from