RFC3164] for BSD syslog). The IETF Syslog Protocol [RFC5424] introduces a layered architecture allowing the use of any number of transport protocols, including reliable and secure transports, for transmission of syslog messages. The Syslog protocol enables a machine to send system log messages across networks to event message collectors. The protocol is simply designed to transport and distribute these event messages. By default, no acknowledgements of the receipt are made, except the reliable delivery extensions specified in [RFC3195] are used. The Syslog protocol and process does not require a stringent coordination between the transport sender and the receiver. Indeed, the transmission of syslog messages may be started on a device without a receiver being configured, or even actually physically present. Conversely, many devices will most likely be able to receive messages without explicit configuration or definitions. BSD syslog had little uniformity for the message format and the content of syslog messages. The body of a BSD syslog message has traditionally been unstructured text. This content is human friendly, but difficult to parse for applications. With the Syslog Protocol [RFC5424], the IETF has standardized a new message header format, including timestamp, hostname, application, and message ID, to improve filtering, interoperability, and correlation between compliant implementations. The Syslog protocol [RFC5424] also introduces a mechanism for defining Structured Data Elements (SDEs). The SDEs allow vendors to define their own structured data elements to supplement standardized elements. [RFC5675] defines a mapping from SNMP notifications to
syslog messages. [RFC5676] defines an SNMP MIB module to represent syslog messages for the purpose of sending those syslog messages as notifications to SNMP notification receivers. [RFC5674] defines the way alarms are sent in syslog, which includes the mapping of ITU- perceived severities onto syslog message fields and a number of alarm-specific definitions from ITU-T X.733 [ITU-X733] and the IETF Alarm MIB [RFC3877]. "Signed Syslog Messages" [RFC5848] defines a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages to be used in conjunction with the Syslog protocol. The Syslog protocol's layered architecture provides support for a number of transport mappings. For interoperability purposes and especially in managed networks, where the network path has been explicitly provisioned for UDP syslog traffic, the Syslog protocol can be used over UDP [RFC5426]. However, to support congestion control and reliability, [RFC5426] strongly recommends the use of the TLS transport. Furthermore, the IETF defined the TLS Transport Mapping for syslog in [RFC5425], which provides a secure connection for the transport of syslog messages. [RFC5425] describes the security threats to syslog and how TLS can be used to counter such threats. [RFC6012] defines the Datagram Transport Layer Security (DTLS) Transport Mapping for syslog, which can be used if a connectionless transport is desired. For information on MIB modules related to syslog, see Section 4.2.1. RFC5101] defines a push-based data export mechanism for transferring IP flow information in a compact binary format from an Exporter to a Collector. "Architecture for IP Flow Information Export" (the IPFIX Architecture) [RFC5470] defines the components involved in IP flow measurement and reporting of information on IP flows, particularly, a Metering Process generating Flow Records, an Exporting Process that sends metered flow information using the IPFIX protocol, and a Collecting Process that receives flow information as IPFIX Data Records.
After listing the IPFIX requirements in [RFC3917], NetFlow Version 9 [RFC3954] was taken as the basis for the IPFIX protocol and the IPFIX architecture. IPFIX can run over different transport protocols. The IPFIX Protocol [RFC5101] specifies Stream Control Transmission Protocol (SCTP) [RFC4960] as the mandatory transport protocol to implement. Optional alternatives are TCP [STD07] and UDP [STD06]. SCTP is used with its Partial Reliability extension (PR-SCTP) specified in [RFC3758]. [RFC6526] specifies an extension to [RFC5101], when using the PR-SCTP [RFC3758]. The extension offers several advantages over IPFIX export, e.g., the ability to calculate Data Record losses for PR-SCTP, immediate reuse of Template IDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. IPFIX transmits IP flow information in Data Records containing IPFIX Information Elements (IEs) defined by the IPFIX Information Model [RFC5102]. IPFIX IEs are quantities with unit and semantics defined by the Information Model. When transmitted over the IPFIX protocol, only their values need to be carried in Data Records. This compact encoding allows efficient transport of large numbers of measured flow values. Remaining redundancy in Data Records can be further reduced by the methods described in [RFC5473] (for further discussion on IPFIX IEs, see Section 4). The IPFIX Information Model is extensible. New IEs can be registered at IANA (see "IPFIX Information Elements" in [IANA-PROT]). IPFIX also supports the use of proprietary, i.e., enterprise-specific IEs. The PSAMP protocol [RFC5476] extends the IPFIX protocol by means of transferring information on individual packets. [RFC5475] specifies a set of sampling and filtering techniques for IP packet selection, based on the PSAMP Framework [RFC5474]. The PSAMP Information Model [RFC5477] provides a set of basic IEs for reporting packet information with the IPFIX/PSAMP protocol. The IPFIX model of an IP traffic flow is unidirectional. [RFC5103] adds means of reporting bidirectional flows to IPFIX, for example, both directions of packet flows of a TCP connection. When enterprise-specific IEs are transmitted with IPFIX, a Collector receiving Data Records may not know the type of received data and cannot choose the right format for storing the contained information. [RFC5610] provides a means of exporting extended type information for enterprise-specific Information Elements from an Exporter to a Collector.
Collectors may store received flow information in files. The IPFIX file format [RFC5655] can be used for storing IP flow information in a way that facilitates exchange of traffic flow information between different systems and applications. In terms of IPFIX and PSAMP configurations, the Metering and Exporting Processes are configured out of band. As the IPFIX protocol is a push mechanism only, IPFIX cannot configure the Exporter. The actual configuration of selection processes, caches, Exporting Processes, and Collecting Processes of IPFIX- and PSAMP- compliant monitoring devices is executed using the NETCONF protocol [RFC6241] (see Section 2.4.1). The "Configuration Data Model for IPFIX and PSAMP" (the IPFIX Configuration Data Model) [CONF-MODEL] has been specified using Unified Modeling Language (UML) class diagrams. The data model is formally defined using the YANG modeling language [RFC6020] (see Section 2.4.2). At the time of this writing, a framework for IPFIX flow mediation is in preparation, which addresses the need for mediation of flow information in IPFIX applications in large operator networks, e.g., for aggregating huge amounts of flow data and for anonymization of flow information (see the problem statement in [RFC5982]). The IPFIX Mediation Framework [RFC6183] defines the intermediate device between Exporters and Collectors, which provides an IPFIX mediation by receiving a record stream from, e.g., a Collecting Process, hosting one or more Intermediate Processes to transform this stream, and exporting the transformed record stream into IPFIX messages via an Exporting Process. Examples for mediation functions are flow aggregation, flow selection, and anonymization of traffic information (see [RFC6235]). Privacy, integrity, and authentication of the Exporter and Collector are important security requirements for IPFIX [RFC3917]. Confidentiality, integrity, and authenticity of IPFIX data transferred from an Exporting Process to a Collecting Process must be ensured. The IPFIX and PSAMP protocols do not define any new security mechanisms and rely on the security mechanism of the underlying transport protocol, such as TLS [RFC5246] and DTLS [RFC6347]. The primary goal of IPFIX is the reporting of the flow accounting for flexible flow definitions and usage-based accounting. As described in the IPFIX Applicability Statement [RFC5472], there are also other applications such as traffic profiling, traffic engineering, intrusion detection, and QoS monitoring, that require flow-based traffic measurements and can be realized using IPFIX. Furthermore,
the IPFIX Applicability Statement explains the relation of IPFIX to other framework and protocols such as PSAMP, RMON (Remote Network Monitoring MIB, Section 4.2.1), and IPPM (IP Performance Metrics, Section 3.4)). Similar flow information could be also used for security monitoring. The addition of Performance Metrics in the IPFIX IANA registry [IANA-IPFIX], will extend the IPFIX use case to performance management. Note that even if the initial IPFIX focus has been around IP flow information exchange, non-IP-related IEs are now specified in the IPFIX IANA registration (e.g., MAC (Media Access Control) address, MPLS (Multiprotocol Label Switching) labels, etc.). At the time of this writing, there are requests to widen the focus of IPFIX and to export non-IP related IEs (such as SIP monitoring IEs). The IPFIX structured data [RFC6313] is an extension to the IPFIX protocol, which supports hierarchical structured data and lists (sequences) of Information Elements in Data Records. This extension allows the definition of complex data structures such as variable- length lists and specification of hierarchical containment relationships between templates. Furthermore, the extension provides the semantics to express the relationship among multiple list elements in a structured Data Record. For information on data models related to the management of the IPFIX and PSAMP protocols, see Sections 4.2.1 and 4.2.2. For information on IPFIX/PSAMP IEs, see Section 4.2.3. RFC3535] determined advanced requirements for configuration management: o robustness: Minimizing disruptions and maximizing stability, o a task-oriented view, o extensibility for new operations, o standardized error handling, o clear distinction between configuration data and operational state, o distribution of configurations to devices under transactional constraints,
o single- and multi-system transactions and scalability in the number of transactions and managed devices, o operations on selected subsets of management data, o dumping and reloading a device configuration in a textual format in a standard manner across multiple vendors and device types, o a human interface and a programmatic interface, o a data modeling language with a human-friendly syntax, o easy conflict detection and configuration validation, and o secure transport, authentication, and robust access control. The NETCONF protocol [RFC6241] provides mechanisms to install, manipulate, and delete the configuration of network devices and aims to address the configuration management requirements pointed out in the IAB workshop. It uses an XML-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple and reliable Remote Procedure Call (RPC) layer. A key aspect of NETCONF is that it allows the functionality of the management protocol to closely mirror the native command-line interface of the device. The NETCONF working group developed the NETCONF Event Notifications Mechanism as an optional capability, which provides an asynchronous message notification delivery service for NETCONF [RFC5277]. The NETCONF notification mechanism enables using general purpose notification streams, where the originator of the notification stream can be any managed device (e.g., SNMP notifications). The NETCONF Partial Locking specification introduces fine-grained locking of the configuration datastore to enhance NETCONF for fine- grained transactions on parts of the datastore [RFC5717]. The NETCONF working group also defined the necessary data model to monitor the NETCONF protocol [RFC6022], by using the modeling language YANG [RFC6020] (see Section 2.4.2). The monitoring data model includes information about NETCONF datastores, sessions, locks, and statistics, which facilitate the management of a NETCONF server. NETCONF connections are required to provide authentication, data integrity, confidentiality, and replay protection. NETCONF depends on the underlying transport protocol for this capability. For example, connections can be encrypted in TLS or SSH, depending on the underlying protocol.
The NETCONF working group defined the SSH transport protocol as the mandatory transport binding [RFC6242]. Other optional transport bindings are TLS [RFC5539], Blocks Extensible Exchange Protocol (BEEP) over TLS [RFC4744], and Simple Object Access Protocol (SOAP) over HTTP over TLS [RFC4743]. The NETCONF Access Control Model (NACM) [RFC6536] provides standard mechanisms to restrict protocol access to particular users with a pre-configured subset of operations and content. RFC3535], the NETMOD working group developed a data modeling language defining the semantics of operational and configuration data, notifications, and operations [RFC6020]. The new data modeling language, called YANG, maps directly to XML-encoded content (on the wire) and will serve as the normative description of NETCONF data models. YANG has the following properties addressing specific requirements on a modeling language for configuration management: o YANG provides the means to define hierarchical data models. It supports reusable data types and groupings, i.e., a set of schema nodes that can be reused across module boundaries. o YANG supports the distinction between configuration and state data. In addition, it provides support for modeling event notifications and the specification of operations that extend the base NETCONF operations. o YANG allows the expression of constraints on data models by means of type restrictions and XML Path Language (XPATH) 1.0 [XPATH] expressions. XPATH expressions can also be used to make certain portions of a data model conditional. o YANG supports the integration of standard- and vendor-defined data models. YANG's augmentation mechanism allows the seamless augmentation of standard data models with proprietary extensions. o YANG data models can be partitioned into collections of features, allowing low-end devices only to implement the core features of a data model while high-end devices may choose to support all features. The supported features are announced via the NETCONF capability exchange to management applications.
o The syntax of the YANG language is compact and optimized for human readers. An associated XML-based syntax called the YANG Independent Notation (YIN) [RFC6020] is available to allow the processing of YANG data models with XML-based tools. The mapping rules for the translation of YANG data models into Document Schema Definition Languages (DSDL), of which RELAX NG is a major component, are defined in [RFC6110]. o Devices implementing standard data models can document deviations from the data model in separate YANG modules. Applications capable of discovering deviations can make allowances that would otherwise not be possible. A collection of common data types for IETF-related standards is provided in [RFC6021]. This standard data type library has been derived to a large extend from common SMIv2 data types, generalizing them to a less-constrained NETCONF Framework. The document "An Architecture for Network Management using NETCONF and YANG" describes how NETCONF and YANG can be used to build network management applications that meet the needs of network operators [RFC6244]. The Experimental RFC [RFC6095] specifies extensions for YANG, introducing language abstractions such as class inheritance and recursive data structures. [RFC6087] gives guidelines for the use of YANG within the IETF and other standardization organizations. Work is underway to standardize a translation of SMIv2 data models into YANG data models preserving investments into SNMP MIB modules, which are widely available for monitoring purposes [SMI-YANG]. Several independent and open source implementations of the YANG data modeling language and associated tools are available. While YANG is a relatively recent data modeling language, some data models have already been produced. The specification of the base NETCONF protocol operations has been revised and uses YANG as the normative modeling language to specify its operations [RFC6241]. The IPFIX working group prepared the normative model for configuring and monitoring IPFIX- and PSAMP-compliant monitoring devices using the YANG modeling language [CONF-MODEL].
At the time of this writing, the NETMOD working group is developing core system and interface data models. Following the example of the IPFIX configuration model, IETF working groups will prepare models for their specific needs. For information on data models developed using the YANG modeling language, see Sections 4.2.1 and 4.2.2. RFC2131] provides a framework for passing configuration information to hosts on a TCP/IP network and, as such, enables autoconfiguration in IP networks. In addition to IP address management, DHCP can also provide other configuration information, such as default routers, the IP addresses of recursive DNS servers, and the IP addresses of NTP servers. As described in [RFC6272], DHCP can be used for IPv4 and IPv6 Address Allocation and Assignment as well as for Service Discovery. There are two versions of DHCP: one for IPv4 (DHCPv4) [RFC2131] and one for IPv6 (DHCPv6) [RFC3315]. DHCPv4 was defined as an extension to BOOTP (Bootstrap Protocol) [RFC0951]. DHCPv6 was subsequently defined to accommodate new functions required by IPv6 such as assignment of multiple addresses to an interface and to address limitations in the design of DHCPv4 resulting from its origins in BOOTP. While both versions bear the same name and perform the same functionality, the details of DHCPv4 and DHCPv6 are sufficiently different that they can be considered separate protocols. In addition to the assignment of IP addresses and other configuration information, DHCP options like the Relay Agent Information option (DHCPv4) [RFC3046] and, the Interface-Id Option (DHCPv6) [RFC3315] are widely used by ISPs. DHCPv6 includes Prefix Delegation [RFC3633], which is used to provision a router with an IPv6 prefix for use in the subnetwork supported by the router.
The following are examples of DHCP options that provide configuration information or access to specific servers. A complete list of DHCP options is available at [IANA-PROT]. o "DNS Configuration options for Dynamic Host Configuration Protocol for IPV6 (DHCPv6)" [RFC3646] describes DHCPv6 options for passing a list of available DNS recursive name servers and a domain search list to a client. o "DHCP Options for Service Location Protocol" [RFC2610] describes DHCPv4 options and methods through which entities using the Service Location Protocol can find out the address of Directory Agents in order to transact messages and how the assignment of scope for configuration of Service Location Protocol (SLP) User and Service Agents can be achieved. o "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers" [RFC3319] specifies DHCPv6 options that allow SIP clients to locate a local SIP server that is to be used for all outbound SIP requests, a so-called "outbound proxy server". o "Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers" [RFC4280] defines DHCPv6 options to discover the Broadcast and Multicast Service (BCMCS) controller in an IP network. Built directly on UDP and IP, DHCP itself has no security provisions. There are two different classes of potential security issues related to DHCP: unauthorized DHCP Servers and unauthorized DHCP Clients. The recommended solutions to these risks generally involve providing security at lower layers, e.g., careful control over physical access to the network, security techniques implemented at Layer 2 but also IPsec at Layer 3 can be used to provide authentication. RFC5889], which describes the addressing model for ad hoc networks and how nodes in these networks configure their addresses. The ad hoc nodes under consideration are expected to be able to support multi-hop communication by running MANET (Mobile Ad Hoc Network) routing protocols as developed by the IETF MANET working group.
From the IP layer perspective, an ad hoc network presents itself as a Layer 3 multi-hop network formed over a collection of links. The addressing model aims to avoid problems for parts of the system that are ad hoc unaware, such as standard applications running on an ad hoc node or regular Internet nodes attached to the ad hoc nodes. RFC4213] specifies IPv4 compatibility mechanisms for dual-stack and configured tunneling that can be implemented by IPv6 hosts and routers. "Dual stack" implies providing complete implementations of both IPv4 and IPv6, and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures. o "Transition Scenarios for 3GPP Networks" [RFC3574] lists different scenarios in 3GPP defined packet network that would need IPv6 and IPv4 transition, where "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks" [RFC4215] does a more detailed analysis of the transition scenarios that may come up in the deployment phase of IPv6 in 3GPP packet networks. o "Scenarios and Analysis for Introducing IPv6 into ISP Networks" [RFC4029] describes and analyzes different scenarios for the introduction of IPv6 into an ISP's existing IPv4 network. "IPv6 Deployment Scenarios in 802.16 Networks" [RFC5181] provides a detailed description of IPv6 deployment, integration methods, and scenarios in wireless broadband access networks (802.16) in coexistence with deployed IPv4 services. [RFC4057] describes the scenarios for IPv6 deployment within enterprise networks. o "Application Aspects of IPv6 Transition" [RFC4038] specifies scenarios and application aspects of IPv6 transition considering how to enable IPv6 support in applications running on IPv6 hosts, and giving guidance for the development of IP-version-independent applications. o "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598] updates RFC 5735 and requested the allocation of an IPv4/10 address block to be used as "Shared Carrier-Grade Network Address
Translation (CGN) Space" by Service Providers to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE). RFC2753] for managing, sharing, and reusing policies in a vendor-independent, interoperable, and scalable manner. [RFC3460] specifies the Policy Core Information Model (PCIM) as an object-oriented information model for representing policy information. PCIM has been developed jointly in the IETF Policy Framework (POLICY) working group and the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). PCIM has been published as extensions to CIM [DMTF-CIM]. The IETF Policy Framework is based on a policy-based admission control specifying two main architectural elements: the Policy Enforcement Point (PEP) and the Policy Decision Point (PDP). For the purpose of network management, policies allow an operator to specify how the network is to be configured and monitored by using a descriptive language. Furthermore, it allows the automation of a number of management tasks, according to the requirements set out in the policy module. The IETF Policy Framework has been accepted by the industry as a standard-based policy management approach and has been adopted by different SDOs, e.g., for 3GGP charging standards. RFC3159] defines the Structure of Policy Provisioning Information (SPPI), an extension to the SMIv2 modeling language used to write Policy Information Base (PIB) modules. COPS-PR [RFC3084] uses the Common Open Policy Service (COPS) protocol [RFC2748] for the provisioning of policy information. COPS provides a simple client/ server model for supporting policy control over QoS signaling protocols. The COPS-PR specification is independent of the type of policy being provisioned (QoS, security, etc.) but focuses on the mechanisms and conventions used to communicate provisioned information between policy-decision-points (PDPs) and policy enforcement points (PEPs). Policy data is modeled using PIB modules. COPS-PR has not been widely deployed, and operators have stated that its use of binary encoding for management data makes it difficult to develop automated scripts for simple configuration management tasks
in most text-based scripting languages. In the IAB Workshop on Network Management [RFC3535], the consensus of operators and protocol developers indicated a lack of interest in PIB modules for use with COPS-PR. As a result, even if COPS-PR and the Structure of Policy Provisioning Information (SPPI) were initially approved as Proposed Standards, the IESG has not approved any PIB modules as Proposed Standard, and the use of COPS-PR is not recommended. Section 1.2 ("Related Work") but especially to [OAM-OVERVIEW].
The following are essential IPPM documents: o "Framework for IP Performance Metrics" [RFC2330] defines a general framework for particular metrics developed by the IPPM working group, and it defines the fundamental concepts of 'metric' and 'measurement methodology'. It also discusses the issue of measurement uncertainties and errors as well as introduces the notion of empirically defined metrics and how metrics can be composed. o "A One-way Delay Metric for IPPM" [RFC2679] defines a metric for the one-way delay of packets across Internet paths. It builds on notions introduced in the IPPM Framework document. o "A Round-trip Delay Metric for IPPM" [RFC2681] defines a metric for the round-trip delay of packets across network paths and closely follows the corresponding metric for one-way delay. o "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)" [RFC3393] refers to a metric for variation in the delay of packets across network paths and is based on the difference in the one-way-delay of selected packets called "IP Packet Delay Variation (ipdv)". o "A One-way Packet Loss Metric for IPPM" [RFC2680] defines a metric for one-way packet loss across Internet paths. o "A One-Way Packet Duplication Metric" [RFC5560] defines a metric for the case where multiple copies of a packet are received, and it discusses methods to summarize the results of streams. o "Packet Reordering Metrics" [RFC4737] defines metrics to evaluate whether a network has maintained packet order on a packet-by- packet basis and discusses the measurement issues, including the context information required for all metrics. o "IPPM Metrics for Measuring Connectivity" [RFC2678] defines a series of metrics for connectivity between a pair of Internet hosts. o "Framework for Metric Composition" [RFC5835] describes a detailed framework for composing and aggregating metrics. o "Guidelines for Considering New Performance Metric Development" [BCP170] describes the framework and process for developing Performance Metrics of protocols and applications transported over IETF-specified protocols.
To measure these metrics, two protocols and a sampling method have been standardized: o "A One-way Active Measurement Protocol (OWAMP)" [RFC4656] measures unidirectional characteristics such as one-way delay and one-way loss between network devices and enables the interoperability of these measurements. OWAMP is discussed in more detail in [OAM-OVERVIEW]. o "A Two-Way Active Measurement Protocol (TWAMP)" [RFC5357] adds round-trip or two-way measurement capabilities to OWAMP. TWAMP is discussed in more detail in [OAM-OVERVIEW]. o "Network performance measurement with periodic streams" [RFC3432] describes a periodic sampling method and relevant metrics for assessing the performance of IP networks, as an alternative to the Poisson sampling method described in [RFC2330]. For information on MIB modules related to IP Performance Metrics see Section 4.2.4. RFC2865] describes a client/server protocol for carrying authentication, authorization, and configuration information between a Network Access Server (NAS), which desires to authenticate its links, and a shared authentication server. The companion document "Radius Accounting" [RFC2866] describes a protocol for carrying accounting information between a NAS and a shared accounting server. [RFC2867] adds required new RADIUS accounting attributes and new values designed to support the provision of tunneling in dial-up networks. The RADIUS protocol is widely used in environments like enterprise networks, where a single administrative authority manages the network and protects the privacy of user information. RADIUS is deployed in the networks of fixed broadband access provider as well as cellular broadband operators. RADIUS uses attributes to carry the specific authentication, authorization, information, and configuration details. RADIUS is extensible with a known limitation of a maximum of 255 attribute codes and 253 octets as attribute content length. RADIUS has Vendor- Specific Attributes (VSAs), which have been used both for vendor- specific purposes (as an addition to standardized attributes) as well as to extend the limited attribute code space.
The RADIUS protocol uses a shared secret along with the MD5 hash algorithm to secure passwords [RFC1321]. Based on the known threads, additional protection like IPsec tunnels [RFC4301] are used to further protect the RADIUS traffic. However, building and administering large IPsec-protected networks may become a management burden, especially when the IPsec-protected RADIUS infrastructure should provide inter-provider connectivity. Moving towards TLS-based security solutions [RFC5246] and establishing dynamic trust relationships between RADIUS servers has become a trend. Since the introduction of TCP transport for RADIUS [RFC6613], it became natural to have TLS support for RADIUS. An ongoing work is "Transport Layer Security (TLS) encryption for RADIUS" [RFC6614]. "RADIUS Attributes for Tunnel Protocol Support" [RFC2868] defines a number of RADIUS attributes designed to support the compulsory provision of tunneling in dial-up network access. Some applications involve compulsory tunneling, i.e., the tunnel is created without any action from the user and without allowing the user any choice in the matter. In order to provide this functionality, specific RADIUS attributes are needed to carry the tunneling information from the RADIUS server to the tunnel end points. "Signalling Connection Control Part User Adaptation Layer (SUA)" [RFC3868] defines the necessary attributes, attribute values, and the required IANA registries. "RADIUS and IPv6" [RFC3162] specifies the operation of RADIUS over IPv6 and the RADIUS attributes used to support the IPv6 network access. "RADIUS Delegated-IPv6-Prefix Attribute" [RFC4818] describes how to transport delegated IPv6 prefix information over RADIUS. "RADIUS Attributes for Virtual LAN and Priority Support" [RFC4675] defines additional attributes for dynamic Virtual LAN assignment and prioritization, for use in provisioning of access to IEEE 802 local area networks usable with RADIUS and diameter. "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes" [RFC5080] describes common issues seen in RADIUS implementations and suggests some fixes. Where applicable, unclear statements and errors in previous RADIUS specifications are clarified. People designing extensions to RADIUS protocol for various deployment cases should get familiar with "RADIUS Design Guidelines" [RFC6158] in order to avoid, e.g., known interoperability challenges. "RADIUS Extension for Digest Authentication" [RFC5090] defines an extension to the RADIUS protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP.
"Carrying Location Objects in RADIUS and DIAMETER" [RFC5580] describes procedures for conveying access-network ownership and location information based on civic and geospatial location formats in RADIUS and diameter. "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management" [RFC5607] specifies required RADIUS attributes and their values for authorizing a management access to a NAS. Both local and remote management are supported, with access rights and management privileges. Specific provisions are made for remote management via Framed Management protocols, such as SNMP and NETCONF, and for management access over a secure transport protocol. "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)" [RFC3579] describes how to use RADIUS to convey an EAP [RFC3748] payload between the authenticator and the EAP server using RADIUS. RFC 3579 is widely implemented, for example, in WLAN and 802.1 X environments. "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines" [RFC3580] describes how to use RADIUS with IEEE 802.1X authenticators. In the context of 802.1X and EAP-based authentication, the VSAs described in [RFC2458] have been widely accepted by the industry. "RADIUS Extensions" [RFC2869] is another important RFC related to EAP use. RFC 2869 describes additional attributes for carrying AAA information between a NAS and a shared accounting server using RADIUS. It also defines attributes to encapsulate EAP message payload. There are different MIB modules defined for multiple purposes to use with RADIUS (see Sections 4.2.3 and 4.2.5). RFC3588] provides an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in local AAA and in roaming scenarios. Diameter provides an upgrade path for RADIUS but is not directly backwards compatible. Diameter is designed to resolve a number of known problems with RADIUS. Diameter supports server failover, reliable transport over TCP and SCTP, well-documented functions for proxy, redirect and relay agent functions, server-initiated messages, auditability, and capability negotiation. Diameter also provides a larger attribute space for Attribute-Value Pairs (AVPs) and identifiers than RADIUS. Diameter features make it especially appropriate for environments,
where the providers of services are in different administrative domains than the maintainer (protector) of confidential user information. Other notable differences to RADIUS are as follows: o Network and Transport Layer Security (IPsec or TLS), o Stateful and stateless models, o Dynamic discovery of peers (using DNS Service Record (SRV) and Naming Authority Pointer (NAPTR)), o Concept of an application that describes how a specific set of commands and Attribute-Value Pairs (AVPs) are treated by diameter nodes. Each application has an IANA-assigned unique identifier, o Support of application layer acknowledgements, failover methods and state machines, o Basic support for user-sessions and accounting, o Better roaming support, o Error notification, and o Easy extensibility. The Diameter protocol is designed to be extensible to support, e.g., proxies, brokers, mobility and roaming, Network Access Servers (NASREQ), and Accounting and Resource Management. Diameter applications extend the Diameter base protocol by adding new commands and/or attributes. Each application is defined by a unique IANA- assigned application identifier and can add new command codes and/or new mandatory AVPs. The Diameter application identifier space has been divided into Standards Track and 'First Come First Served' vendor-specific applications. The following are examples of Diameter applications published at IETF: o Diameter Base Protocol Application [RFC3588]: Required support from all Diameter implementations. o Diameter Base Accounting Application [RFC3588]: A Diameter application using an accounting protocol based on a server- directed model with capabilities for real-time delivery of accounting information.
o Diameter Mobile IPv4 Application [RFC4004]: A Diameter application that allows a Diameter server to authenticate, authorize, and collect accounting information for Mobile IPv4 services rendered to a mobile node. o Diameter Network Access Server Application (NASREQ, [RFC4005]): A Diameter application used for AAA services in the NAS environment. o Diameter Extensible Authentication Protocol Application [RFC4072]: A Diameter application that carries EAP packets between a NAS and a back-end authentication server. o Diameter Credit-Control Application [RFC4006]: A Diameter application that can be used to implement real-time credit-control for a variety of end-user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. o Diameter Session Initiation Protocol Application [RFC4740]: A Diameter application designed to be used in conjunction with SIP and provides a Diameter client co-located with a SIP server, with the ability to request the authentication of users and authorization of SIP resources usage from a Diameter server. o Diameter Quality-of-Service Application [RFC5866]: A Diameter application allowing network elements to interact with Diameter servers when allocating QoS resources in the network. o Diameter Mobile IPv6 IKE (MIP6I) Application [RFC5778]: A Diameter application that enables the interaction between a Mobile IP home agent and a Diameter server and is used when the mobile node is authenticated and authorized using IKEv2 [RFC5996]. o Diameter Mobile IPv6 Auth (MIP6A) Application [RFC5778]: A Diameter application that enables the interaction between a Mobile IP home agent and a Diameter server and is used when the mobile node is authenticated and authorized using the Mobile IPv6 Authentication Protocol [RFC4285]. The large majority of Diameter applications are vendor-specific and mainly used in various SDOs outside the IETF. One example SDO using diameter extensively is 3GPP (e.g., 3GPP 'IP Multimedia Subsystem' (IMS) uses diameter-based interfaces (e.g., Cx) [3GPPIMS]). Recently, during the standardization of the '3GPP Evolved Packet Core' [3GPPEPC], diameter was chosen as the only AAA signaling protocol.
One part of diameter's extensibility mechanism is an easy and consistent way of creating new commands for the need of applications. RFC 3588 proposed to define diameter command code allocations with a new RFC. This policy decision caused undesired use and redefinition of existing command codes within SDOs. Diverse RFCs have been published as simple command code allocations for other SDO purposes (see [RFC3589], [RFC5224], [RFC5431], and [RFC5516]). [RFC5719] changed the command code policy and added a range for vendor-specific command codes to be allocated on a 'First Come First Served' basis by IANA. The implementation and deployment experience of diameter has led to the ongoing development of an update of the base protocol [DIAMETER], which introduces TLS as the preferred security mechanism and deprecates the in-band security negotiation for TLS. Some Diameter protocol enhancements and clarifications that logically fit better into [DIAMETER], are also needed on the existing deployments based on RFC 3588. Therefore, protocol extensions specifically usable in large inter-provider roaming network scenarios are made available for RFC 3588. Two currently existing specifications are mentioned below: o "Clarifications on the Routing of Diameter Requests Based on the Username and the Realm" [RFC5729] defines the behavior required for Diameter agents to route requests when the User-Name AVP contains a NAI formatted with multiple realms. These multi-realm Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms. o "Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage" [RFC6408] describes an improved DNS-based dynamic Diameter agent discovery mechanism without having to do diameter capability exchange beforehand with a number of agents. There have been a growing number of Diameter Framework documents from the IETF that basically are just a collection of AVPs for a specific purpose or a system architecture with semantic AVP descriptions and a logic for "imaginary" applications. From a standardization point of view, this practice allows the development of larger system architecture documents that do not need to reference AVPs or application logic outside the IETF. Below are examples of a few recent AVP and Framework documents:
o "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction" [RFC5447] describes the bootstrapping of the Mobile IPv6 framework and the support of interworking with existing AAA infrastructures by using the diameter NAS-to-home-AAA server interface. o "Traffic Classification and Quality of Service (QoS) Attributes for Diameter" [RFC5777] defines a number of Diameter AVPs for traffic classification with actions for filtering and QoS treatment. o "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server" [RFC5779] defines AAA interactions between Proxy Mobile IPv6 (PMIPv6) entities (MAG and LMA) and a AAA server within a PMIPv6 Domain. For information on MIB modules related to diameter, see Section 4.2.5. RFC4118], the CAPWAP working group developed the CAPWAP protocol [RFC5415] to facilitate control, management, and provisioning of WTPs specifying the services, functions, and resources relating to 802.11 WLAN Termination Points in order to allow for interoperable implementations of WTPs and ACs. The protocol defines the CAPWAP control plane, including the primitives to control data access. The protocol document also specifies how configuration management of WTPs can be done and defines CAPWAP operations responsible for debugging, gathering statistics, logging, and managing firmware as well as discusses operational and transport considerations. The CAPWAP protocol is prepared to be independent of Layer 2 technologies, and meets the objectives in "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)" [RFC4564]. Separate
binding extensions enable the use with additional wireless technologies. [RFC5416] defines the CAPWAP Protocol Binding for IEEE 802.11. CAPWAP Control messages, and optionally CAPWAP Data messages, are secured using DTLS [RFC6347]. DTLS is used as a tightly integrated, secure wrapper for the CAPWAP protocol. For information on MIB modules related to CAPWAP, see Section 4.2.2. RFC6320] realizes a control plane between a service-oriented Layer 3 edge device, the NAS and a Layer 2 Access Node (AN), e.g., Digital Subscriber Line Access Module (DSLAM). As such, ANCP operates in a multi-service reference architecture and communicates QoS-, service-, and subscriber-related configuration and operation information between a NAS and an AN. The main goal of this protocol is to configure and manage access equipment and allow them to report information to the NAS in order to enable and optimize configuration. The framework and requirements for an AN control mechanism and the use cases for ANCP are documented in [RFC5851]. ANCP offers authentication and authorization between AN and NAS nodes and provides replay protection and data-origin authentication. The ANCP solution is also robust against Denial-of-Service (DoS) attacks. Furthermore, the ANCP solution is recommended to offer confidentiality protection. Security Threats and Security Requirements for ANCP are discussed in [RFC5713]. RFC2244] is designed to support remote storage and access of program option, configuration, and preference information. The datastore model is designed to allow a client relatively simple access to interesting data, to allow new information to be easily added without server reconfiguration, and to promote the use of both standardized data and custom or proprietary data. Key features include "inheritance", which can be used to manage default values for configuration settings and access control lists that allow interesting personal information to be shared and group information to be restricted.
ACAP's primary purpose is to allow applications access to their configuration data from multiple network-connected computers. Users can then use any network-connected computer, run any ACAP-enabled application, and have access to their own configuration data. To enable wide usage client simplicity has been preferred to server or protocol simplicity whenever reasonable. The ACAP 'authenticate' command uses Simple Authentication and Security Layer (SASL) [RFC4422] to provide basic authentication, authorization, integrity, and privacy services. All ACAP implementations are required to implement the CRAM-MD5 (Challenge- Response Authentication Mechanism) [RFC2195] for authentication, which can be disabled based on the site security policy. RFC4825] has been designed for and is commonly used with SIP- based solutions, in particular, for instant messages, presence, and SIP conferences. XCAP is a protocol that allows a client to read, write, and modify application configuration data stored in XML format on a server, where the main functionality is provided by so-called "XCAP Application Usages". XCAP is a protocol that can be used to manipulate per-user data. XCAP is a set of conventions for mapping XML documents and document components into HTTP URIs, rules for how the modification of one resource affects another, data validation constraints, and authorization policies associated with access to those resources. Because of this structure, normal HTTP primitives can be used to manipulate the data. Like ACAP, XCAP supports the configuration needs for a multiplicity of applications. All XCAP servers are required to implement HTTP Digest Authentication [RFC2617]. Furthermore, XCAP servers are required to implement HTTP over TLS (HTTPS) [RFC2818]. It is recommended that administrators use an HTTPS URI as the XCAP root URI, so that the digest client authentication occurs over TLS. The following list summarizes important XCAP application usages: o XCAP server capabilities [RFC4825] can be read by clients to determine which extensions, application usages, or namespaces a server supports. o A resource lists application is any application that needs access to a list of resources, identified by a URI, to which operations, such as subscriptions, can be applied [RFC4826].
o A Resource List Server (RLS) Services application is a SIP application, where a server receives SIP SUBSCRIBE requests for resources and generates subscriptions towards the resource list [RFC4826]. o A Presence Rules application uses authorization policies, also known as authorization rules, to specify what presence information can be given to which watchers, and when [RFC4827]. o A 'pidf-manipulation' application defines how XCAP is used to manipulate the contents of PIDF-based presence documents [RFC4827].