Management Information Base for the Session Initiation Protocol (SIP)
RFC 4780

Global Routing Operations                                     P. Lucente
Internet-Draft                                                       NTT
Updates: 7854 (if approved)                                        Y. Gu
Intended status: Standards Track                                  Huawei
Expires: 19 September 2024                                 18 March 2024

  Support for Enterprise-specific TLVs in the BGP Monitoring Protocol
                    draft-ietf-grow-bmp-tlv-ebit-05

Abstract

   Message types defined by the BGP Monitoring Protocol (BMP) do
   provision for data in TLV - Type, Length, Value - format, either in
   the shape of a TLV message body, ie.  Route Mirroring and Stats
   Reports, or optional TLVs at the end of a BMP message, ie.  Peer Up
   and Peer Down.  However the space for Type value is unique and
   governed by IANA.  To allow the usage of vendor-specific TLVs, a
   mechanism to define per-vendor Type values is required.  In this
   document we introduce an Enterprise Bit, or E-bit, for such purpose.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 19 September 2024.

Copyright Notice

   Copyright (c) 2024 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 (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components

Lucente & Gu            Expires 19 September 2024               [Page 1]
Internet-Draft                BMP TLV EBIT                    March 2024

   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  TLV encoding  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  IANA-registered TLV encoding  . . . . . . . . . . . . . .   3
     3.2.  Enterprise-specific TLV encoding  . . . . . . . . . . . .   3
     3.3.  TLV encoding remarks  . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  Operational Considerations  . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   The BGP Monitoring Protocol (BMP) is defined in RFC 7854 [RFC7854].
   Support for TLV data is extended by TLV support for BMP Route
   Monitoring and Peer Down Messages [I-D.ietf-grow-bmp-tlv].

   Vendors need the ability to define proprietary Information Elements
   for various reasons such as delivering a pre-standard product.  This
   aligns with Section 4.1 of [RFC8126].

   Also for code point assignment to be eligible, an IETF document needs
   to be adopted at a Working Group and in a stable condition.  In this
   context E-bit helps during early development phases where inter-
   operability among vendors is tested and shipped to network operators
   for testing.  This aligns with Section 4.2 of [RFC8126].

   This document re-defines the format of IANA-registered TLVs in a
   backward compatible manner with respect to previous documents and
   existing IANA allocations; it also defines the format for newly
   introduced enterprise-specific TLVs.

   The concept of an E-bit, or Enterprise Bit, is not new.  For example,
   such mechanism is defined in Section 3.2 of [RFC7011] for a very
   similar purpose.

Lucente & Gu            Expires 19 September 2024               [Page 2]


   The sipCommonCfgTable table contains some objects that may help
   attackers gain knowledge about the status and operations of the SIP
   service.  In particular, the object value of
   sipCommonCfgServiceOperStatus may indicate that the SIP entity is in
   congested state and may lead attackers to build additional service
   attacks to overload the system.

   The sipCommonCfgEntityType object indicates the type of SIP entity,
   and the sipCommonMethodSupportedTable table contains in the SIP-
   COMMON-MIB MIB module list of SIP methods supported by each entity in
   the system.  Gaining access to this information may allow attackers
   to build method-specific attacks or use unsupported methods to create
   denial-of-service attack scenarios.

   In the SIP-UA-MIB MIB module, the sipUACfgServerTable contains the
   address of the SIP servers providing services to the UA, and
   obtaining this information may disclose some private or sensitive
   information about the SIP service usage.

   In the SIP-SERVER-MIB MIB module, the sipServerCfgProxyAuthMethod
   object defines the authentication methods supported by the server and
   may be used to build specific denial-of-service attackers targeted at
   the security mechanisms employed by the SIP entity.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPsec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this set of MIB modules.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see RFC 3410 [RFC3410]), including
   full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   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
   responsi when bility to ensure that the SNMP entity giving access to
   an instance of this MIB module is properly configured to give access
   to the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

Lingle, et al.              Standards Track                    [Page 79]
RFC 4780                    SIP MIB Modules                   April 2007

10.  Contributor Acknowledgments

   We wish to thank the members of the IETF SIP and SIPPING working
   groups, and the SIP-MIB Design team for their comments and
   suggestions.  Detailed comments were provided by Tom Taylor, Kavitha
   Patchayappan, Dan Romascanu, Cullen Jennings, Orit Levin, AC
   Mahendran, Mary Barnes, Rohan Mahy, Bob Penfield, Charles Eckel, and
   Dean Willis.  Special thanks to Bert Wijnen for his expert reviews,
   which have greatly improved the SIP MIB modules.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP:  Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC2578]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
              "Structure of Management Information Version 2 (SMIv2)",
              STD 58, RFC 2578, April 1999.

   [RFC2579]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
              "Textual Conventions for SMIv2", STD 58, RFC 2579, April
              1999.

   [RFC2580]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
              "Conformance Statements for SMIv2", STD 58, RFC 2580,
              April 1999.

   [RFC2788]  Freed, N. and S. Kille, "Network Services Monitoring MIB",
              RFC 2788, March 2000.

   [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.

   [RFC4001]  Daniele, M., Haberman, B., Routhier, S., and J.
              Schoenwaelder, "Textual Conventions for Internet Network
              Addresses", RFC 4001, February 2005.

Lingle, et al.              Standards Track                    [Page 80]
RFC 4780                    SIP MIB Modules                   April 2007

11.2.  Informative References

   [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
              "Introduction and Applicability Statements for Internet-
              Standard Management Framework", RFC 3410, December 2002.

   [RFC3262]  Rosenberg, J. and H. Schulzrinne, "Reliability of
              Provisional Responses in Session Initiation Protocol
              (SIP)", RFC 3262, June 2002.

   [RFC4168]  Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The
              Stream Control Transmission Protocol (SCTP) as a Transport
              for the Session Initiation Protocol (SIP)", RFC 4168,
              October 2005.

Lingle, et al.              Standards Track                    [Page 81]
RFC 4780                    SIP MIB Modules                   April 2007

Authors' Addresses

   Kevin Lingle
   Cisco Systems, Inc.
   7025 Kit Creek Road
   P.O. Box 14987
   Research Triangle Park, NC  27709
   US

   Phone: +1 919 476 2029
   EMail: klingle@cisco.com

   Jean-Francois Mule
   CableLabs
   858 Coal Creek Circle
   Louisville, CO  80027
   US

   Phone: +1 303 661 9100
   EMail: jf.mule@cablelabs.com

   Joon Maeng
   5612 Sedona Drive
   Austin, TX  78759
   US

   Phone: +1 512 418 0590
   EMail: jmaeng@austin.rr.com

   Dave Walker

   EMail: drwalker@rogers.com

Lingle, et al.              Standards Track                    [Page 82]
RFC 4780                    SIP MIB Modules                   April 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Lingle, et al.              Standards Track                    [Page 83]