<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="UTF-8"?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?> <?rfc toc="yes"?> <?rfc compact="no"?> <?rfc subcompact="no"?> <?rfc symrefs="yes" ?> <?rfc sortrefs="yes"?> <?rfc iprnotified="no"?> <?rfc strict="yes"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-ipsecme-mib-iptfs-11"submissionType="IETF"number="9349" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.14.2 --> <front> <titleabbrev="draft-ietf-ipsecme-mib-iptfs-11">Definitionsabbrev="Definitions of Managed Objects for IP-TFS">Definitions of Managed Objects for IP Traffic Flow Security</title> <seriesInfoname="Internet-Draft" value="draft-ietf-ipsecme-mib-iptfs-11"/>name="RFC" value="9349"/> <!-- <title abbrev="Definitions of Managed Objects for IP-TFS">Definitions of Managed Objects for IP Traffic Flow Security</title> --> <author initials="D." surname="Fedyk" fullname="Don Fedyk"> <organization>LabN Consulting, L.L.C.</organization> <address> <email>dfedyk@labn.net</email> </address> </author> <author initials="E." surname="Kinzie" fullname="Eric Kinzie"> <organization>LabN Consulting, L.L.C.</organization> <address> <email>ekinzie@labn.net</email> </address> </author><date/><date year="2023" month="January"/> <area>sec</area> <workgroup>ipsecme</workgroup> <keyword>MIB</keyword> <keyword>IPsec</keyword> <keyword>IP-TRAFFIC-FLOW-SECURITY-MIB</keyword> <abstract> <t>This document describes managed objects for the management of IP Traffic Flow Security additions toIKEv2Internet Key Exchange Protocol Version 2 (IKEv2) and IPsec. This document provides aread onlyread-only version of the objects defined in the YANG module for the samepurpose.purpose, which is in "A YANG Data Model for IP Traffic Flow Security" (RFC 9348). </t> </abstract> </front> <middle> <section numbered="true" toc="default"> <name>Introduction</name> <t>This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. IP Traffic Flow Security (IP-TFS)extensionsextensions, as defined in <xreftarget="I-D.ietf-ipsecme-iptfs" format="default"/>target="RFC9347" format="default"/>, are enhancements to an IPsec tunnel Security Association (SA) to provide improved traffic confidentiality. </t> <t> The objects defined here are the same as <xref target="RFC9348" format="default"/>, with the exception that only operational or state data is supported. By making operational data accessible via SNMP, existing network management systems can monitor IP-TFS. This data is listed in the MIB tree in <xref target ="mib-tree" format="default"/>. This module uses the YANG data model as a reference point for managed objects. Note that an IETF MIB model for IPsec was never standardized; however, the structures here could be adapted to existing proprietary MIB implementations where SNMP is used to manage networks. </t> <section numbered="true" toc="default"> <name>The Internet-Standard Management Framework</name> <!-- DNE starts --> <t> For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer tosection 7 of<xref target="RFC3410" section="7" sectionFormat="of" format="default"/>. </t> <t> Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined 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, <xref target="RFC2578" format="default"/>, STD 58, <xref target="RFC2579" format="default"/> and STD 58, <xref target="RFC2580" format="default"/>. </t><t> The objects defined here are the same as <xref target="I-D.ietf-ipsecme-yang-iptfs" format="default"/> with the exception that only operational or state data is supported. By making operational data accessible via SNMP existing network management systems can monitor IP-TFS. This data is listed in the MIB tree in <xref target ="mib-tree" format="default"/>. This module uses the YANG model as a reference point for managed objects. Note an IETF MIB model for IPsec was never standardized however the structures here could be adapted to existing proprietary MIB implementations where SNMP is used to manage networks. </t><!-- DNE ends --> </section> </section> <section numbered="true" toc="default"> <name>Terminology&and Concepts</name><t>The<t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xreftarget="RFC2119" format="default"/>target="RFC2119"/> <xreftarget="RFC8174" format="default"/>target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <section numbered="true" toc="default"> <name>Overview</name> <t>This document defines the MIB for access to operational parameters of IPtraffic flow securityTraffic Flow Security (IP-TFS). IP-TFS, defined in <xreftarget="I-D.ietf-ipsecme-iptfs"target="RFC9347" format="default"/>, configures asecurity associationSecurity Association for tunnel mode IPsec with characteristics that improve traffic confidentiality and reduce bandwidth efficiency loss. </t> <t> This document is based on the concepts and management model defined in <xreftarget="I-D.ietf-ipsecme-yang-iptfs"target="RFC9348" format="default"/>. This document assumes familiarity withIP securitythe IPsec concepts described in <xref target="RFC4301" format="default"/>, IP-TFS as described in <xreftarget="I-D.ietf-ipsecme-iptfs" format="default"/>target="RFC9347" format="default"/>, and the IP-TFS management model described in <xreftarget="I-D.ietf-ipsecme-yang-iptfs"target="RFC9348" format="default"/>. </t> <t> This document specifies an extensible operational model for IP-TFS. It reuses the management model defined in <xreftarget="I-D.ietf-ipsecme-yang-iptfs"target="RFC9348" format="default"/>. It allows SNMP systems to read operational objects (whichincludesinclude configured objects) from IP-TFS. </t> </section> <section numbered="true" toc="default"> <name>Management Objects</name> <section anchor="mib-tree" numbered="true" toc="default"> <name>MIB Tree</name> <t>The following is the MIB registration tree diagram for the IP-TFS extensions.</t> <artwork name="" type="" align="left" alt=""><![CDATA[ # IP-TRAFFIC-FLOW-SECURITY-MIB registration tree --iptfsMIB(1.3.6.1.2.1.500) +--iptfsMIBObjects(1) | +--iptfsGroup(1) | | +--iptfsConfigTable(1) | | +--iptfsConfigTableEntry(1) [iptfsConfigSaIndex] | | | | | +-- --- Integer32 iptfsConfigSaIndex(1) | | +-- r-n TruthValue congestionControl(2) | | +-- r-n TruthValue usePathMtuDiscovery(3) | | +-- r-n UnsignedShort outerPacketSize(4) | | +-- r-n CounterBasedGauge64 l2FixedRate(5) | | +-- r-n CounterBasedGauge64 l3FixedRate(6) | | +-- r-n TruthValue dontFragment(7) | | +-- r-n NanoSeconds maxAggregationTime(8) | | +-- r-n UnsignedShort windowSize(9) | | +-- r-n TruthValue sendImmediately(10) | | +-- r-n NanoSeconds lostPacketTimerInterval(11) | +--ipsecStatsGroup(2) | | +--ipsecStatsTable(1) | | +--ipsecStatsTableEntry(1) [ipsecSaIndex] | | +-- --- Integer32 ipsecSaIndex(1) | | +-- r-n Counter64 txPkts(2) | | +-- r-n Counter64 txOctets(3) | | +-- r-n Counter64 txDropPkts(4) | | +-- r-n Counter64 rxPkts(5) | | +-- r-n Counter64 rxOctets(6) | | +-- r-n Counter64 rxDropPkts(7) | +--iptfsInnerStatsGroup(3) | | +--iptfsInnerStatsTable(1) | | +--iptfsInnerStatsTableEntry(1) [iptfsInnerSaIndex] | | +-- --- Integer32 iptfsInnerSaIndex(1) | | +-- r-n Counter64 txInnerPkts(2) | | +-- r-n Counter64 txInnerOctets(3) | | +-- r-n Counter64 rxInnerPkts(4) | | +-- r-n Counter64 rxInnerOctets(5) | | +-- r-n Counter64 rxIncompleteInnerPkts(6) | +--iptfsOuterStatsGroup(4) | +--iptfsOuterStatsTable(1) | +--iptfsOuterStatsTableEntry(1)[iptfsSaIndex][iptfsOuterSaIndex] | +-- --- Integer32iptfsSaIndex(1)iptfsOuterSaIndex(1) | +-- r-n Counter64 txExtraPadPkts(2) | +-- r-n Counter64 txExtraPadOctets(3) | +-- r-n Counter64 txAllPadPkts(4) | +-- r-n Counter64 txAllPadOctets(5) | +-- r-n Counter64 rxExtraPadPkts(6) | +-- r-n Counter64 rxExtraPadOctets(7) | +-- r-n Counter64 rxAllPadPkts(8) | +-- r-n Counter64 rxAllPadOctets(9) | +-- r-n Counter64 rxErroredPkts(10) | +-- r-n Counter64 rxMissedPkts(11) +--iptfsMIBConformance(2) +--iptfsMIBConformances(1) | +--iptfsMIBCompliance(1) +--iptfsMIBGroups(2) +--iptfsMIBConfGroup(1) +--ipsecStatsConfGroup(2) +--iptfsInnerStatsConfGroup(3) +--iptfsOuterStatsConfGroup(4) ]]></artwork> </section> <section numbered="true" toc="default"> <name>SNMP</name> <t>The following is the MIB for IP-TFS. TheCongestioncongestion control algorithm in <xref target="RFC5348" format="default"/> is referenced in the MIB text.</t> <sourcecode name="iptfs-mib.mib" type="mib"markers="true"><![CDATA[=-->markers="true"><![CDATA[ -- *---------------------------------------------------------------- -- * IP-TRAFFIC-FLOW-SECURITY-MIB Module -- *---------------------------------------------------------------- IP-TRAFFIC-FLOW-SECURITY-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, Counter64, mib-2 FROM SNMPv2-SMI CounterBasedGauge64 FROM HCNUM-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION, TruthValue FROM SNMPv2-TC; iptfsMIB MODULE-IDENTITY LAST-UPDATED"202210210000Z""202301090000Z" ORGANIZATION "IETF IPsecme Working Group" CONTACT-INFO " Author: Don Fedyk <mailto:dfedyk@labn.net> Author: Eric Kinzie <mailto:ekinzie@labn.net>"-- RFC Ed.: replace XXXX with actual RFC number, update mib-2 -- entry and remove this note.DESCRIPTION "This module defines the configuration and operational state for managing the IP Traffic Flow Security functionality[RFC XXXX].(RFC 9349). Copyright (c)20222023 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 (https://trustee.ietf.org/license-info). This version of this SNMP MIB module is part of RFCXXXX (https://tools.ietf.org/html/rfcXXXX);9349; see the RFC itself for full legal notices." REVISION"202210210000Z""202301090000Z" DESCRIPTION "Initial revision. Derived from the IP-TFSYangYANG Data Model." ::= { mib-2500}246} -- -- Textual Conventions -- UnsignedShort ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "xs:unsignedShort" SYNTAX Unsigned32 (0 .. 65535) NanoSeconds ::= TEXTUAL-CONVENTION DISPLAY-HINT "d-6" STATUS current DESCRIPTION "Represents the time unit value in nanoseconds." SYNTAX Integer32 -- Objects, Notifications & Conformances iptfsMIBObjects OBJECT IDENTIFIER ::= { iptfsMIB 1 } iptfsMIBConformance OBJECT IDENTIFIER ::= { iptfsMIB 2} -- -- IP-TFS MIB Object Groups -- iptfsGroup OBJECT IDENTIFIER ::= { iptfsMIBObjects 1 } ipsecStatsGroup OBJECT IDENTIFIER ::= { iptfsMIBObjects 2 } iptfsInnerStatsGroup OBJECT IDENTIFIER ::= { iptfsMIBObjects 3 } iptfsOuterStatsGroup OBJECT IDENTIFIER ::= { iptfsMIBObjects 4 } iptfsConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF IptfsConfigTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing configuration information for IP-TFS." ::= { iptfsGroup 1 } iptfsConfigTableEntry OBJECT-TYPE SYNTAX IptfsConfigTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular IP-TFS SA." INDEX { iptfsConfigSaIndex } ::= { iptfsConfigTable 1 } IptfsConfigTableEntry ::= SEQUENCE { iptfsConfigSaIndex Integer32, -- identifier information congestionControl TruthValue, usePathMtuDiscovery TruthValue, outerPacketSize UnsignedShort, l2FixedRate CounterBasedGauge64, l3FixedRate CounterBasedGauge64, dontFragment TruthValue, maxAggregationTime NanoSeconds, windowSize UnsignedShort, sendImmediately TruthValue, lostPacketTimerInterval NanoSeconds } iptfsConfigSaIndex OBJECT-TYPE SYNTAX Integer32 (1..16777215) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value, greater than zero, for each SA. It is recommended that values are assignedcontiguouslycontiguously, starting from 1. The value for each entry must remain constant at least from one re-initialization of an entity's network management system to the next re-initialization." ::= { iptfsConfigTableEntry 1 } congestionControl OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "When set to true, the default, this enables the congestion control on-the-wire exchange of data that is required by congestion controlalgorithmsalgorithms, as defined by RFC 5348. When set to false, IP-TFS sends fixed-sized packets over an IP-TFS tunnel at a constant rate." ::= { iptfsConfigTableEntry 2 } usePathMtuDiscovery OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Packet size is either auto-discovered or manually configured. If usePathMtuDiscovery istruetrue, the system utilizes path-mtu to determine the maximum IP-TFS packet size. If the packet size is explicitlyconfiguredconfigured, then it will only be adjusted downward if use-path-mtu is set." ::= { iptfsConfigTableEntry 3 } outerPacketSize OBJECT-TYPE SYNTAX UnsignedShort MAX-ACCESS read-only STATUS current DESCRIPTION "OnTransmission,transmission, the size of the outer encapsulating tunnel packet (i.e., the IP packet containingthe ESP payload)."Encapsulating Security Payload)." ::= { iptfsConfigTableEntry 4 } l2FixedRate OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION"IP-TFS"The IP-TFS bit rate may be specified as a layer 2 wire rate. On transmission, the target bandwidth/bit rate inbpsbits per second (bps) for the IP-TFS tunnel. This rate is the nominal timing for thefixed sizefixed-size packet. If congestion control isenabledenabled, the rate may be adjusted down." ::= { iptfsConfigTableEntry 5 } l3FixedRate OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION"IP-TFS"The IP-TFS bit rate may be specified as a layer 3 packet rate. OnTransmission,transmission, the target bandwidth/bit rate in bps for the IP-TFS tunnel. This rate is the nominal timing for thefixed sizefixed-size packet. If congestion control isenabledenabled, the rate may be adjusted down." ::= { iptfsConfigTableEntry 6 } dontFragment OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "On transmission, disable packet fragmentation across consecutive IP-TFS tunnel packets; inner packets larger than what can be transmitted in outer packets will be dropped." ::= { iptfsConfigTableEntry 7 } maxAggregationTime OBJECT-TYPE SYNTAX NanoSeconds MAX-ACCESS read-only STATUS current DESCRIPTION "On transmission, the maximum aggregation time is the maximum length of time a received inner packet can be held prior to transmission in the IP-TFS tunnel. Inner packets that would be held longer than this time, based on the current tunnelconfigurationconfiguration, will be dropped rather than be queued for transmission." ::= { iptfsConfigTableEntry 8 } windowSize OBJECT-TYPE SYNTAX UnsignedShort MAX-ACCESS read-only STATUS current DESCRIPTION "On reception, the maximum number of out-of-order packets that will be reordered by an IP-TFS receiver while performing the reordering operation. The value 0 disables any reordering." ::= { iptfsConfigTableEntry 9 } sendImmediately OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "On reception, send inner packets as soon aspossible,possible; do not wait for lost or misordered outer packets. Selecting this option reduces the inner (user) packet delay but can amplify out-of-order delivery of the inner packet stream in the presence of packet aggregation and any reordering." ::= { iptfsConfigTableEntry 10 } lostPacketTimerInterval OBJECT-TYPE SYNTAX NanoSeconds MAX-ACCESS read-only STATUS current DESCRIPTION "On reception, this interval defines the length of time an IP-TFS receiver will wait for a missing packet before considering it lost. If not using send-immediately, then each lost packet will delay inner (user) packets until this timer expires. Setting this value too low can impact reordering and reassembly." ::= { iptfsConfigTableEntry 11 } ipsecStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IpsecStatsTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing basic statistics on IPsec." ::= { ipsecStatsGroup 1 } ipsecStatsTableEntry OBJECT-TYPE SYNTAX IpsecStatsTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular IKE SA." INDEX { ipsecSaIndex } ::= { ipsecStatsTable 1 } IpsecStatsTableEntry ::= SEQUENCE { ipsecSaIndex Integer32, -- packet statistics information txPkts Counter64, txOctets Counter64, txDropPkts Counter64, rxPkts Counter64, rxOctets Counter64, rxDropPkts Counter64 } ipsecSaIndex OBJECT-TYPE SYNTAX Integer32 (1..16777215) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value, greater than zero, for each SA. It is recommended that values are assignedcontiguouslycontiguously, starting from 1. The value for each entry must remain constant at least from one re-initialization of an entity's network management system to the next re-initialization." ::= { ipsecStatsTableEntry 1 } txPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Outbound Packet count." ::= { ipsecStatsTableEntry 2 } txOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Outbound Packet bytes." ::= { ipsecStatsTableEntry 3 } txDropPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Outbound dropped packets count." ::= { ipsecStatsTableEntry 4 } rxPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Inbound Packet count." ::= { ipsecStatsTableEntry 5 } rxOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Inbound Packet bytes." ::= { ipsecStatsTableEntry 6 } rxDropPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "InboundDropped packets"dropped packets." ::= { ipsecStatsTableEntry 7 } iptfsInnerStatsTable OBJECT-TYPE SYNTAX SEQUENCE OFIptfsInnerSaEntryIptfsInnerStatsSaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing information on IP-TFSInner Packets."inner packets." ::= { iptfsInnerStatsGroup 1 } iptfsInnerStatsTableEntry OBJECT-TYPE SYNTAXIptfsInnerSaEntryIptfsInnerStatsSaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing the information on a particular IP-TFS SA." INDEX { iptfsInnerSaIndex } ::= { iptfsInnerStatsTable 1 }IptfsInnerSaEntryIptfsInnerStatsSaEntry ::= SEQUENCE { iptfsInnerSaIndex Integer32, txInnerPkts Counter64, txInnerOctets Counter64, rxInnerPkts Counter64, rxInnerOctets Counter64, rxIncompleteInnerPkts Counter64 } iptfsInnerSaIndex OBJECT-TYPE SYNTAX Integer32 (1..16777215) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value, greater than zero, for each SA. It is recommended that values are assignedcontiguouslycontiguously, starting from 1. The value for each entry must remain constant at least from one re-initialization of an entity's network management system to the next re-initialization." ::= { iptfsInnerStatsTableEntry 1 } txInnerPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of IP-TFS inner packets sent. This count is whole packets only. A fragmented packet counts as one packet." ::= { iptfsInnerStatsTableEntry 2 } txInnerOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of IP-TFS inner octets sent. This is inner packet octets only.DoesThis does not count padding." ::= { iptfsInnerStatsTableEntry 3 } rxInnerPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of IP-TFS inner packets received." ::= { iptfsInnerStatsTableEntry 4 } rxInnerOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of IP-TFS inner octets received.DoesThis does not include padding or overhead." ::= { iptfsInnerStatsTableEntry 5 } rxIncompleteInnerPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of IP-TFS inner packets that were incomplete.UsuallyUsually, this is due to fragments not received. Also, this may be due to misordering or errors in received outer packets." ::= { iptfsInnerStatsTableEntry 6 } iptfsOuterStatsTable OBJECT-TYPE SYNTAX SEQUENCE OFIptfsOuterSaEntryIptfsOuterStatsSaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing information on IP-TFS." ::= { iptfsOuterStatsGroup 1 } iptfsOuterStatsTableEntry OBJECT-TYPE SYNTAXIptfsOuterSaEntryIptfsOuterStatsSaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing the information on a particular IP-TFS SA." INDEX {iptfsSaIndexiptfsOuterSaIndex } ::= { iptfsOuterStatsTable 1 }IptfsOuterSaEntryIptfsOuterStatsSaEntry ::= SEQUENCE {iptfsSaIndexiptfsOuterSaIndex Integer32, -- iptfs packet statistics information txExtraPadPkts Counter64, txExtraPadOctets Counter64, txAllPadPkts Counter64, txAllPadOctets Counter64, rxExtraPadPkts Counter64, rxExtraPadOctets Counter64, rxAllPadPkts Counter64, rxAllPadOctets Counter64, rxErroredPkts Counter64, rxMissedPkts Counter64 }iptfsSaIndexiptfsOuterSaIndex OBJECT-TYPE SYNTAX Integer32 (1..16777215) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value, greater than zero, for each SA. It is recommended that values are assignedcontiguouslycontiguously, starting from 1. The value for each entry must remain constant at least from one re-initialization of an entity's network management system to the next re-initialization." ::= { iptfsOuterStatsTableEntry 1 } txExtraPadPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of transmitted outer IP-TFS packets that included some padding." ::= { iptfsOuterStatsTableEntry 2 } txExtraPadOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of transmitted octets of padding added to outer IP-TFS packets with data." ::= { iptfsOuterStatsTableEntry 3 } txAllPadPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of transmitted IP-TFS packets that were all padding with no inner packet data." ::= { iptfsOuterStatsTableEntry 4 } txAllPadOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number transmitted octets of padding added to IP-TFS packets with no inner packet data." ::= { iptfsOuterStatsTableEntry 5 } rxExtraPadPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of received outer IP-TFS packets that included some padding." ::= { iptfsOuterStatsTableEntry 6 } rxExtraPadOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of received octets of padding added to outer IP-TFS packets with data." ::= { iptfsOuterStatsTableEntry 7 } rxAllPadPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of received IP-TFS packets that were all padding with no inner packet data." ::= { iptfsOuterStatsTableEntry 8 } rxAllPadOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number received octets of padding added to IP-TFS packets with no inner packet data." ::= { iptfsOuterStatsTableEntry 9 } rxErroredPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of IP-TFS outer packets dropped due to errors." ::= { iptfsOuterStatsTableEntry 10 } rxMissedPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of IP-TFS outer packets missing indicated by a missing sequence number." ::= { iptfsOuterStatsTableEntry 11 } -- -- Iptfs Module Compliance -- iptfsMIBConformances OBJECT IDENTIFIER ::= { iptfsMIBConformance 1 } iptfsMIBGroups OBJECT IDENTIFIER ::= { iptfsMIBConformance 2 } iptfsMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entitieswhichthat implement the IP-TFSMIB"MIB." MODULE -- this module MANDATORY-GROUPS { iptfsMIBConfGroup, ipsecStatsConfGroup, iptfsInnerStatsConfGroup, iptfsOuterStatsConfGroup } ::= { iptfsMIBConformances 1 } -- -- MIB Groups (Units of Conformance) -- iptfsMIBConfGroup OBJECT-GROUP OBJECTS { congestionControl, usePathMtuDiscovery, outerPacketSize , l2FixedRate , l3FixedRate , dontFragment, maxAggregationTime, windowSize, sendImmediately, lostPacketTimerInterval } STATUS current DESCRIPTION "A collection of objects providing per SA IP-TFSConfiguration."configuration." ::= { iptfsMIBGroups 1 } ipsecStatsConfGroup OBJECT-GROUP OBJECTS { txPkts, txOctets, txDropPkts, rxPkts, rxOctets, rxDropPkts } STATUS current DESCRIPTION "A collection of objects providing per SABasic Stats."basic statistics." ::= { iptfsMIBGroups 2 } iptfsInnerStatsConfGroup OBJECT-GROUP OBJECTS { txInnerPkts, txInnerOctets, rxInnerPkts, rxInnerOctets, rxIncompleteInnerPkts } STATUS current DESCRIPTION "A collection of objects providing per SA IP-TFSInner Packet Statistics."inner packet statistics." ::= { iptfsMIBGroups 3 } iptfsOuterStatsConfGroup OBJECT-GROUP OBJECTS { txExtraPadPkts, txExtraPadOctets, txAllPadPkts, txAllPadOctets, rxExtraPadPkts, rxExtraPadOctets, rxAllPadPkts, rxAllPadOctets, rxErroredPkts, rxMissedPkts } STATUS current DESCRIPTION "A collection of objects providing per SA IP-TFSOuter Packet Statistics."outer packet statistics." ::= { iptfsMIBGroups 4 } END ]]></sourcecode> </section> </section> <section numbered="true" toc="default"> <name>IANA Considerations</name> <t> The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER value, recorded in theSMI"SMI Network Management MGMT Codes Internet-standardMIB -MIB" registry: </t><artwork name="" type="" align="left" alt=""><![CDATA[ Name Description OBJECT IDENTIFIER value ------- --------------------------------- ---------------------- iptfsMIB IP-TRAFFIC-FLOW-SECURITY-MIB { mib-2 TBA-IANA } ]]></artwork><table align="left"> <thead> <tr> <th>Decimal</th> <th>Name</th> <th>Description</th> </tr> </thead> <tbody> <tr> <td>246</td> <td>iptfsMIB</td> <td>IP-TRAFFIC-FLOW-SECURITY-MIB</td> </tr> </tbody> </table> </section> <section numbered="true" toc="default"> <name>Security Considerations</name> <t>The MIB specified in this document can read the operational behavior of IPtraffic flow security.Traffic Flow Security. For the implications regarding writeconfigurationconfiguration, consultthe<xreftarget="I-D.ietf-ipsecme-iptfs" format="default"/>target="RFC9347" format="default"/>, which defines the functionality.</t> <!-- DNE starts --> <t> There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations. </t> <t> Some of the objects in this MIB module may be considered sensitive or vulnerable in some network environments. This includes INDEX objects with a MAX-ACCESS of not-accessible, and any indices from other modules exposed via AUGMENTS. It is thus 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: </t> <!-- DNE ends --> <ul spacing="normal"> <li> iptfsInnerStatsTable andiptfsOuterStatsTable-iptfsOuterStatsTable: Access to IP inner and outertraffic flow securityTraffic Flow Security statistics can provide information that IPtraffic flow security obscuresTraffic Flow Security obscures, such as the true activity of the flows using IPtraffic flow security.Traffic Flow Security. </li> </ul> <!-- DNE starts --> <t> SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), there is no control as to who on the secure network is allowed to access and GET (read) the objects in this MIB module. </t> <t>To prevent unauthorized access to SNMP including access to IP-TFS sensitive objects: </t> <ul spacing="normal"> <li>ImplementationsSHOULD<bcp14>SHOULD</bcp14> provide the security features described by the SNMPv3 framework (see <xref target="RFC3410" format="default"/>), and implementations claiming compliance to the SNMPv3 standardMUST<bcp14>MUST</bcp14> include full support for authentication and privacy via the User-based Security Model (USM) <xref target="RFC3414" format="default"/> with the AES cipher algorithm <xref target="RFC3826" format="default"/>. ImplementationsMAY<bcp14>MAY</bcp14> also provide support for the Transport Security Model (TSM) <xref target="RFC5591" format="default"/> in combination with a secure transport such as SSH <xref target="RFC5592" format="default"/> or TLS/DTLS <xref target="RFC6353" format="default"/>.</li> <li></t> <t> Further, deployment of SNMP versions prior to SNMPv3 isNOT RECOMMENDED.<bcp14>NOT RECOMMENDED</bcp14>. Instead, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> 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.</li> </ul> </section> <section numbered="true" toc="default"> <name>Acknowledgements</name> <t>The authors would like to thank Chris Hopps, Lou Berger and Tero Kivinen for their help and feedback on the MIB model.</t> <!-- DNE ends --> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name><reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC3414" target="https://www.rfc-editor.org/info/rfc3414" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3414.xml"> <front> <title>User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)</title> <author fullname="U. Blumenthal" initials="U." surname="Blumenthal"/> <author fullname="B. Wijnen" initials="B." surname="Wijnen"/> <date month="December" year="2002"/> <abstract> <t>This document describes the User-based Security Model (USM) for Simple Network Management Protocol (SNMP) version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a Management Information Base (MIB) for remotely monitoring/managing the configuration parameters for this Security Model. This document obsoletes RFC 2574. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="62"/> <seriesInfo name="RFC" value="3414"/> <seriesInfo name="DOI" value="10.17487/RFC3414"/> </reference> <reference anchor="RFC3826" target="https://www.rfc-editor.org/info/rfc3826" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3826.xml"> <front> <title>The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model</title> <author fullname="U. Blumenthal" initials="U." surname="Blumenthal"/> <author fullname="F. Maino" initials="F." surname="Maino"/> <author fullname="K. McCloghrie" initials="K." surname="McCloghrie"/> <date month="June" year="2004"/> <abstract> <t>This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="3826"/> <seriesInfo name="DOI" value="10.17487/RFC3826"/> </reference> <reference anchor="RFC5591" target="https://www.rfc-editor.org/info/rfc5591" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5591.xml"> <front> <title>Transport Security Model for the Simple Network Management Protocol (SNMP)</title> <author fullname="D. Harrington" initials="D." surname="Harrington"/> <author fullname="W. Hardaker" initials="W." surname="Hardaker"/> <date month="June" year="2009"/> <abstract> <t>This memo describes a Transport Security Model for the Simple Network Management Protocol (SNMP).</t> <t>This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="78"/> <seriesInfo name="RFC" value="5591"/> <seriesInfo name="DOI" value="10.17487/RFC5591"/> </reference> <reference anchor="RFC5592" target="https://www.rfc-editor.org/info/rfc5592" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5592.xml"> <front> <title>Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)</title> <author fullname="D. Harrington" initials="D." surname="Harrington"/> <author fullname="J. Salowey" initials="J." surname="Salowey"/> <author fullname="W. Hardaker" initials="W." surname="Hardaker"/> <date month="June" year="2009"/> <abstract> <t>This memo describes a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell (SSH) protocol.</t> <t>This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5592"/> <seriesInfo name="DOI" value="10.17487/RFC5592"/> </reference> <reference anchor="RFC6353" target="https://www.rfc-editor.org/info/rfc6353" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6353.xml"> <front> <title>Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)</title> <author fullname="W. Hardaker" initials="W." surname="Hardaker"/> <date month="July" year="2011"/> <abstract> <t>This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of an SNMP Transport Subsystem to make this protection possible in an interoperable way.</t> <t>This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.</t> <t>This<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3414.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3826.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5591.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5592.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6353.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2578.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2579.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2580.xml"/> <!-- [I-D.ietf-ipsecme-iptfs]; companion documentalso defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="78"/> <seriesInfo name="RFC" value="6353"/> <seriesInfo name="DOI" value="10.17487/RFC6353"/> </reference> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <front> <title>Ambiguity of Uppercase vs Lowercase inRFC2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="RFC2578" target="https://www.rfc-editor.org/info/rfc2578" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2578.xml"> <front> <title>Structure of Management Information Version 2 (SMIv2)</title> <author fullname="K. McCloghrie" initials="K." role="editor" surname="McCloghrie"/> <author fullname="D. Perkins" initials="D." role="editor" surname="Perkins"/> <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/> <date month="April" year="1999"/> <abstract> <t>It is the purpose of this document, the Structure of Management Information Version 2 (SMIv2), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="58"/> <seriesInfo name="RFC" value="2578"/> <seriesInfo name="DOI" value="10.17487/RFC2578"/> </reference> <reference anchor="RFC2579" target="https://www.rfc-editor.org/info/rfc2579" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2579.xml"> <front> <title>Textual Conventions for SMIv2</title> <author fullname="K. McCloghrie" initials="K." role="editor" surname="McCloghrie"/> <author fullname="D. Perkins" initials="D." role="editor" surname="Perkins"/> <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/> <date month="April" year="1999"/> <abstract> <t>It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="58"/> <seriesInfo name="RFC" value="2579"/> <seriesInfo name="DOI" value="10.17487/RFC2579"/> </reference>9347 --> <referenceanchor="I-D.ietf-ipsecme-iptfs" target="https://www.ietf.org/archive/id/draft-ietf-ipsecme-iptfs-19.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-ipsecme-iptfs.xml">anchor='RFC9347' target='https://www.rfc-editor.org/info/rfc9347'> <front><title>IP-TFS: Aggregation<title>Aggregation and Fragmentation Mode forESPEncapsulating Security Payload (ESP) anditsIts Use for IP Traffic FlowSecurity</title>Security (IP-TFS)</title> <authorfullname="Christian Hopps"> <organization>LabN Consulting, L.L.C.</organization> </author>initials='C' surname='Hopps' fullname='Christian Hopps'/> <dateday="4" month="September" year="2022"/> <abstract> <t>This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in ESP payloads. This new payload type can be used for various purposes such as decreasing encapsulation overhead for small IP packets; however, the focus in this document is to enhance IPsec traffic flow security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-sized, constant-send-rate IPsec tunnel. The solution allows for congestion control as well as non- constant send-rate usage.</t> </abstract>year='2023' month='January'/> </front> <seriesInfoname="Internet-Draft" value="draft-ietf-ipsecme-iptfs-19"/>name="RFC" value="9347"/> <seriesInfo name="DOI" value="10.17487/RFC9347"/> </reference> </references> <references> <name>Informative References</name> <!-- [I-D.ietf-ipsecme-yang-iptfs]; companion document RFC 9348 --> <referenceanchor="I-D.ietf-ipsecme-yang-iptfs" target="https://www.ietf.org/archive/id/draft-ietf-ipsecme-yang-iptfs-11.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-ipsecme-yang-iptfs.xml">anchor='RFC9348' target='https://www.rfc-editor.org/info/rfc9348'> <front> <title>A YANG Data Model for IP Traffic Flow Security</title> <author initials="D." surname="Fedyk" fullname="DonFedyk"> <organization>LabN Consulting, L.L.C.</organization> </author>Fedyk"/> <author initials="C." surname="Hopps" fullname="ChristianHopps"> <organization>LabN Consulting, L.L.C.</organization> </author> <date day="31" month="August" year="2022"/> <abstract> <t>This document describes a YANG module for the management of IP Traffic Flow Security additions to IKEv2 and IPsec.</t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-ipsecme-yang-iptfs-11"/> </reference> <reference anchor="RFC2580" target="https://www.rfc-editor.org/info/rfc2580" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2580.xml"> <front> <title>Conformance Statements for SMIv2</title> <author fullname="K. McCloghrie" initials="K." role="editor" surname="McCloghrie"/> <author fullname="D. Perkins" initials="D." role="editor" surname="Perkins"/> <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>Hopps"/> <datemonth="April" year="1999"/> <abstract> <t>Collections of related objects are defined in MIB modules. It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]</t> </abstract>month="January" year="2023"/> </front> <seriesInfoname="STD" value="58"/> <seriesInfoname="RFC"value="2580"/>value="9348"/> <seriesInfo name="DOI"value="10.17487/RFC2580"/>value="10.17487/RFC9348"/> </reference><reference anchor="RFC3410" target="https://www.rfc-editor.org/info/rfc3410" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3410.xml"> <front> <title>Introduction and Applicability Statements for Internet-Standard Management Framework</title> <author fullname="J. Case" initials="J." surname="Case"/> <author fullname="R. Mundy" initials="R." surname="Mundy"/> <author fullname="D. Partain" initials="D." surname="Partain"/> <author fullname="B. Stewart" initials="B." surname="Stewart"/> <date month="December" year="2002"/> <abstract><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3410.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5348.xml"/> </references> </references> <section numbered="false" toc="default"> <name>Acknowledgements</name> <t>Thepurpose of this document is to provide an overview of the third version of the Internet-Standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the second Internet-Standard Management Framework (SNMPv2). The architecture is designed to be modular to allow the evolution of the Framework over time. The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="3410"/> <seriesInfo name="DOI" value="10.17487/RFC3410"/> </reference> <reference anchor="RFC4301" target="https://www.rfc-editor.org/info/rfc4301" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"> <front> <title>Security Architecture for the Internet Protocol</title> <author fullname="S. Kent" initials="S." surname="Kent"/> <author fullname="K. Seo" initials="K." surname="Seo"/> <date month="December" year="2005"/> <abstract> <t>This document describes an updated version of the "Security Architecture for IP", which is designedauthors would like toprovide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4301"/> <seriesInfo name="DOI" value="10.17487/RFC4301"/> </reference> <reference anchor="RFC5348" target="https://www.rfc-editor.org/info/rfc5348" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5348.xml"> <front> <title>TCP Friendly Rate Control (TFRC): Protocol Specification</title> <author fullname="S. Floyd" initials="S." surname="Floyd"/> <author fullname="M. Handley" initials="M." surname="Handley"/> <author fullname="J. Padhye" initials="J." surname="Padhye"/> <author fullname="J. Widmer" initials="J." surname="Widmer"/> <date month="September" year="2008"/> <abstract> <t>This document specifies TCP Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best-effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitablethank <contact fullname="Chris Hopps"/>, <contact fullname="Lou Berger"/>, and <contact fullname="Tero Kivinen"/> forapplications such as streaming media where a relatively smooth sending rate is of importance.</t> <t>This document obsoletes RFC 3448their help andupdates RFC 4342. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5348"/> <seriesInfo name="DOI" value="10.17487/RFC5348"/> </reference> </references> </references>feedback on the MIB model. </t> </section> </back> </rfc>