As the table will be created after the sctpAssocTable
creation, this value could be equal to the sctpAssocStartTime
object from the main table."
::= { sctpLookupRemIPAddrEntry 1 }
-- 4.1 Conformance Information
sctpMibConformance OBJECT IDENTIFIER ::= { sctpMIB 2 }
sctpMibCompliances OBJECT IDENTIFIER ::= { sctpMibConformance 1 }
sctpMibGroups OBJECT IDENTIFIER ::= { sctpMibConformance 2 }
-- 4.1.1 Units of conformance
--
-- MODULE GROUPS
--
sctpLayerParamsGroup OBJECT-GROUP
OBJECTS { sctpRtoAlgorithm,
sctpRtoMin,
sctpRtoMax,
sctpRtoInitial,
sctpMaxAssocs,
sctpValCookieLife,
sctpMaxInitRetr
}
STATUS current
DESCRIPTION
"Common parameters for the SCTP layer, i.e., for all the
associations. They can usually be referred to as configuration
parameters."
::= { sctpMibGroups 1 }
sctpStatsGroup OBJECT-GROUP
OBJECTS { sctpCurrEstab,
sctpActiveEstabs,
sctpPassiveEstabs,
sctpAborteds,
sctpShutdowns,
sctpOutOfBlues,
sctpChecksumErrors,
sctpOutCtrlChunks,
sctpOutOrderChunks,
sctpOutUnorderChunks,
sctpInCtrlChunks,
sctpInOrderChunks,
sctpInUnorderChunks,
sctpFragUsrMsgs,
sctpReasmUsrMsgs,
sctpOutSCTPPacks,
sctpInSCTPPacks,
sctpDiscontinuityTime,
sctpAssocT1expireds,
sctpAssocT2expireds,
sctpAssocRtxChunks,
sctpAssocRemAddrRtx
}
STATUS current
DESCRIPTION
"Statistics group. It includes the objects to collect state
changes in the SCTP protocol local layer and flow control
statistics."
::= { sctpMibGroups 2 }
sctpPerAssocParamsGroup OBJECT-GROUP
OBJECTS { sctpAssocRemHostName,
sctpAssocLocalPort,
sctpAssocRemPort,
sctpAssocRemPrimAddrType,
sctpAssocRemPrimAddr,
sctpAssocHeartBeatInterval,
sctpAssocState,
sctpAssocInStreams,
sctpAssocOutStreams,
sctpAssocMaxRetr,
sctpAssocPrimProcess,
sctpAssocStartTime,
sctpAssocDiscontinuityTime,
sctpAssocLocalAddrStartTime,
sctpAssocRemAddrActive,
sctpAssocRemAddrHBActive,
sctpAssocRemAddrRTO,
sctpAssocRemAddrMaxPathRtx,
sctpAssocRemAddrStartTime
}
STATUS current
DESCRIPTION
"The SCTP group of objects to manage per-association
parameters. These variables include all the SCTP basic
features."
::= { sctpMibGroups 3 }
sctpPerAssocStatsGroup OBJECT-GROUP
OBJECTS
{ sctpAssocT1expireds,
sctpAssocT2expireds,
sctpAssocRtxChunks,
sctpAssocRemAddrRtx
}
STATUS current
DESCRIPTION
"Per Association Statistics group. It includes the objects to
collect flow control statistics per association."
::= { sctpMibGroups 4 }
sctpInverseGroup OBJECT-GROUP
OBJECTS { sctpLookupLocalPortStartTime,
sctpLookupRemPortStartTime,
sctpLookupRemHostNameStartTime,
sctpLookupRemPrimIPAddrStartTime,
sctpLookupRemIPAddrStartTime
}
STATUS current
DESCRIPTION
"Objects used in the inverse lookup tables."
::= { sctpMibGroups 5 }
-- 4.1.2 Compliance Statements
--
-- MODULE COMPLIANCES
--
sctpMibCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which implement
this SCTP MIB Module.
There are a number of INDEX objects that cannot be represented
in the form of OBJECT clauses in SMIv2, but for which we have
the following compliance requirements, expressed in OBJECT
clause form in this description clause:
-- OBJECT sctpAssocLocalAddrType
-- SYNTAX InetAddressType {ipv4(1), ipv6(2)}
-- DESCRIPTION
-- It is only required to have IPv4 and IPv6 addresses without
-- zone indices.
-- The address with zone indices is required if an
-- implementation can connect multiple zones.
--
-- OBJECT sctpAssocLocalAddr
-- SYNTAX InetAddress (SIZE(4|16))
-- DESCRIPTION
-- An implementation is only required to support globally
-- unique IPv4 and IPv6 addresses.
--
-- OBJECT sctpAssocRemAddrType
-- SYNTAX InetAddressType {ipv4(1), ipv6(2)}
-- DESCRIPTION
-- It is only required to have IPv4 and IPv6 addresses without
-- zone indices.
-- The address with zone indices is required if an
-- implementation can connect multiple zones.
--
-- OBJECT sctpAssocRemAddr
-- SYNTAX InetAddress (SIZE(4|16))
-- DESCRIPTION
-- An implementation is only required to support globally
-- unique IPv4 and IPv6 addresses.
--
" -- closes DESCRIPTION clause of MODULE-COMPLIANCE
MODULE -- this module
MANDATORY-GROUPS { sctpLayerParamsGroup,
sctpPerAssocParamsGroup,
sctpStatsGroup,
sctpPerAssocStatsGroup
}
OBJECT sctpAssocRemPrimAddrType
SYNTAX InetAddressType { ipv4(1),
ipv6(2)
}
DESCRIPTION
"It is only required to have IPv4 and IPv6 addresses
without zone indices.
The address with zone indices is required if an
implementation can connect multiple zones."
OBJECT sctpAssocRemPrimAddr
SYNTAX InetAddress (SIZE(4|16))
DESCRIPTION
"An implementation is only required to support globally
unique IPv4 and globally unique IPv6 addresses."
OBJECT sctpAssocState
WRITE-SYNTAX INTEGER { deleteTCB(9) }
MIN-ACCESS read-only
DESCRIPTION
"Only the deleteTCB(9) value MAY be set by a management
station at most. A read-only option is also considered to
be compliant with this MIB module description."
GROUP sctpInverseGroup
DESCRIPTION
"Objects used in inverse lookup tables. This should be
implemented, at the discretion of the implementers, for
easier lookups in the association tables"
::= { sctpMibCompliances 1 }
END
5. Compiling Notes
When compiling the MIB module warnings similar to the following may
occur:
- warning: index of row `sctpAssocLocalAddrEntry’ can exceed OID
size limit by 141 subidentifier(s)
- warning: index of row `sctpAssocRemAddrEntry’ can exceed OID
size limit by 141 subidentifier(s)
- warning: index of row `sctpLookupRemHostNameEntry’ can exceed
OID size limit by 140 subidentifier(s)
- warning: index of row `sctpLookupRemPrimIPAddrEntry’ can exceed
OID size limit by 141 subidentifier(s)
- warning: index of row `sctpLookupRemIPAddrEntry’ can exceed OID
size limit by 141 subidentifier(s)
These warnings are due to the fact that the row objects have index
objects of type InetAddress or OCTET STRING whose size limit is 255
octets, and if that size limit were reached the names of column
instances in those rows would exceed the 128 sub-identifier limit
imposed by current versions of the SNMP. Actual limitations for the
index object sizes are noted in the conceptual row DESCRIPTION
clauses. For the InetAddress index objects these size limits will
not be reached with any of the address types in current use.
6. References
6.1. Normative References
[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.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC3291] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 3291, May 2002.
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC 3309,
September 2002.
6.2. Informative References
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets:MIB-
II", STD 17, RFC 1213, March 1991.
[RFC2012] McCloghrie, K., "SNMPv2 Management Information Base for
the Transmission Control Protocol using SMIv2", RFC
2012, November 1996.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for
Internet-Standard Management Framework", RFC 3410,
December 2002.
[VANJ] Jacobson, V., "Congestion Avoidance and Control",
SIGCOMM 1988, Stanford, California.
[IPv6ARCH] Deering, S., Haberman, B., Jinmei, T., Nordmark, E.,
Onoe, A., and B. Zill, "IPv6 Scoped Address
Architecture", Work in Progress, December 2002.
[sctpImplem] Stewart, R., Ong, L., Arias-Rodriguez, I., Caro, A., and
M. Tuexen, "Stream Control Transmission Protocol (SCTP)
Implementers Guide", Work in Progress, January 2002.
[TCPMIB] Fenner, B., McCloghrie, K., Raghunarayan, R., and J.
Schoenwalder, "Management Information Base for the
Transmission Control Protocol (TCP)", Work in Progress,
November 2002.
[UDPMIB] Fenner, B., "Management Information Base for User
Datagram Protocol (UDP)", Work in Progress, June 2002.
[MIBGUIDE] Heard, C.M., "Guidelines for MIB Authors and Reviewers",
Work in Progress, February 2003.
7. Security Considerations
There are management objects defined in this MIB that have a MAX-
ACCESS clause of read-write and/or read-create. Such objects may be
considered sensitive or vulnerable in some network environments. The
support for SET operations in a non-secure environment without proper
protection can have a negative effect on network operations. These
are the tables and objects and their sensitivity/vulnerability:
o The sctpAssocState object has a MAX-ACCESS clause of read-write,
which allows termination of an arbitrary connection. Unauthorized
access could cause a denial of service.
Some of the readable objects in this MIB module (i.e., objects with a
MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments. Thus, it is important to
control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability:
o The sctpAssocTable, sctpAssocLocalAddressTable,
sctpAssocRemAddressTable and the lookup tables contain objects
providing information on the active associations on the device,
local and peer’s IP addresses, the status of these associations
and the associated processes. This information may be used by an
attacker to launch attacks against known/unknown weakness in
certain protocols/applications.
o The sctpAssocTable contains objects providing information on local
and remote ports objects, that can be used to identify what ports
are open on the machine and can thus suggest what attacks are
likely to succeed, without the attacker having to run a port
scanner.
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 MIB module.
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
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
responsibility 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.
The above objects also have privacy implications, i.e., they disclose
who is connecting to what hosts. These are sensitive from a
perspective of preventing traffic analysis, and also to protect
individual privacy.
8. Acknowledgments
The authors wish to thank Juergen Schoenwaelder, David Partain, Shawn
A. Routhier, Ed Yarwood, John Linton, Shyamal Prasad, Juan-Francisco
Martin, Dave Thaler, and Bert Wijnen for their invaluable comments.
9. Authors’ Addresses
Javier Pastor-Balbas
Ericsson Espana S.A.
Network Signaling System Management
Via de los Poblados 13
Madrid, 28033
Spain
Phone: +34-91-339-1397
EMail: J.Javier.Pastor@ericsson.com
Maria-Carmen Belinchon
Ericsson Espana S.A.
Network Signaling System Management
Via de los Poblados 13
Madrid, 28033
Spain
Phone: +34-91-339-3535
EMail: maria.carmen.belinchon@ericsson.com
10. Full Copyright Statement
Copyright (C) The Internet Society (2004).
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/S HE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 IETF’s procedures with respect to rights in IETF 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.