Diameter (protocol)

Last updated May 29, 2024

Diameter is an authentication, authorization, and accounting (AAA) protocol for computer networks. It evolved from the earlier RADIUS protocol. It belongs to the application layer protocols in the Internet protocol suite.

Comparison with RADIUS

The name is a play on words, derived from the RADIUS protocol, which is the predecessor (a diameter is twice the radius). Diameter is not directly backward compatible but provides an upgrade path for RADIUS. The main features provided by Diameter but lacking in RADIUS are:

Support for SCTP
Capability negotiation
Application layer acknowledgements; Diameter defines failover methods and state machines (RFC 3539)
Extensibility; new commands can be defined
Aligned on 32 bit boundaries

Also: Like RADIUS, it is intended to work in both local and roaming AAA situations. It uses TCP or SCTP, unlike RADIUS which uses UDP. Unlike RADIUS it includes no encryption but can be protected by transport-level security (IPSEC or TLS). The base size of the AV identifier is 32 bit unlike RADIUS which uses 8 bit as the base AV identifier size. Like RADIUS, it supports stateless as well as stateful modes. Like RADIUS, it supports application-layer acknowledgment and defines failover. Diameter is used for many different interfaces defined by the 3GPP standards, with each interface typically defining new commands and attributes.

Applications

A Diameter Application is not a software application but is a protocol based on the Diameter base protocol defined in RFC 6733 (obsoletes RFC 3588) and RFC 7075. Each application is defined by an application identifier and can add new command codes and/or new mandatory AVPs (Attribute-Value Pair). Adding a new optional AVP does not require a new application.

Examples of Diameter applications:

Diameter Mobile IPv4 Application (MobileIP, RFC 4004)
Diameter Network Access Server Application (NASREQ, RFC 7155)(Obsoletes: RFC 4005)
Diameter Extensible Authentication Protocol Application (RFC 4072)
Diameter Credit-Control Application (DCCA, RFC 8506])(Obsoletes: RFC 4006)
Diameter Session Initiation Protocol Application (RFC 4740)
Various applications in the 3GPP IP Multimedia Subsystem

Both the HSS and the SLF communicate using the Diameter protocol.

(Generic Bootstrapping Architecture): Bootstrapping Server Function

History

The Diameter protocol was initially developed by Pat R. Calhoun, Glen Zorn, and Ping Pan in 1998 to provide a framework for authentication, authorization, and accounting (AAA) that could overcome the limitations of RADIUS. RADIUS had issues with reliability, scalability, security, and flexibility. RADIUS cannot deal effectively with remote access, IP mobility, and policy control. The Diameter protocol defines a policy protocol used by clients to perform Policy, AAA, and resource control. This allows a single server to handle policies for many services.^[1]

Like RADIUS, Diameter provides AAA functionality, but uses TCP and SCTP instead of UDP, therefore delegating detection and handling of communication problems to those protocols. The Diameter protocol is enhanced further by the development of the 3rd Generation Partnership Project (3GPP) IP Multimedia Subsystem (IMS). The S6a, S6b, Gx, Gy, Sy, Rx, Cx, Dh, Dx, Rf, Ro, Sh and Zh interfaces are supported by Diameter applications.^[2] Through the use of extensions, the protocol was designed to be extensible to support proxies, brokers, strong security, mobile IP, network-access servers (NASREQ), accounting and resource management.

Protocol description

The Diameter base protocol is defined by RFC 6733 (Obsoletes: RFC 3588 and RFC 5719) and defines the minimum requirements for an AAA protocol. Diameter Applications can extend the base protocol by adding new commands, attributes, or both. Diameter security is provided by IPsec or TLS. The IANA has assigned TCP and SCTP port number 3868 to Diameter, as stated in section 11.4 of RFC 6733.

Packet format

The packet consists of a Diameter header and a variable number of Attribute–Value Pairs, or AVPs, for encapsulating information relevant to the Diameter message.

Diameter Header
Bit offset	`0`	`1`	`2`	`3`	`8`
0	version				message length
32	`R`	`P`	`E`	`T`	command code
64	application ID
96	hop-by-hop ID
128	end-to-end ID
160 ...	AVPs ...

Version

This field indicates the version of the Diameter Base Protocol. As of 2014, the only value supported is 1.^[3]

Message length

The Message Length field indicates the length of the Diameter message in bytes, including the header fields and the padded AVPs.

Command flags

The "R" (Request) bit – If set, the message is a request. If cleared, the message is an answer.

The "P" (Proxiable) bit – If set, the message MAY be proxied, relayed or redirected. If cleared, the message MUST be locally processed.

The "E" (Error) bit – If set, the message contains a protocol error, and the message will not conform to the CCF described for this command. Messages with the "E" bit set are commonly referred to as error messages. This bit MUST NOT be set in request messages.

The "T" (Potentially re-transmitted message) bit – This flag is set after a link failover procedure, to aid the removal of duplicate requests. It is set when resending requests not yet acknowledged as an indication of a possible duplicate due to a link failure.

Commands

Each command Request/Answer pair is assigned a command code. Whether it is the request or answer is identified via the 'R' bit in the Command Flags field of the header.

The values 0-255 are reserved for RADIUS backward compatibility. The values 256-16777213 are for permanent, standard commands allocated by IANA. The values 16777214 and 16777215 (hex 0xFFFFFE and 0xFFFFFF) are reserved for experimental and testing purposes.

A Command Code is used to determine the action that is to be taken for a particular message. Some common Diameter commands defined in the protocol (base and applications) are:

Command-Name	Abbr.	Code	Application
AA-Request	AAR	265	Diameter NAS Application - RFC 7155
AA-Answer	AAA	265	Diameter NAS Application - RFC 7155
Diameter-EAP-Request	DER	268	Diameter EAP Application - RFC 4072
Diameter-EAP-Answer	DEA	268	Diameter EAP Application - RFC 4072
Abort-Session-Request	ASR	274	Diameter base
Abort-Session-Answer	ASA	274	Diameter base
Accounting-Request	ACR	271	Diameter base
Accounting-Answer	ACA	271	Diameter base
Credit-Control-Request	CCR	272	Diameter Credit-Control Application - RFC 8506 (Obsoletes RFC 4006)
Credit-Control-Answer	CCA	272	Diameter Credit-Control Application - RFC 8506 (Obsoletes RFC 4006)
Capabilities-Exchange-Request	CER	257	Diameter base
Capabilities-Exchange-Answer	CEA	257	Diameter base
Device-Watchdog-Request	DWR	280	Diameter base
Device-Watchdog-Answer	DWA	280	Diameter base
Disconnect-Peer-Request	DPR	282	Diameter base
Disconnect-Peer-Answer	DPA	282	Diameter base
Re-Auth-Request	RAR	258	Diameter base
Re-Auth-Answer	RAA	258	Diameter base
Session-Termination-Request	STR	275	Diameter base
Session-Termination-Answer	STA	275	Diameter base
User-Authorization-Request	UAR	283	Diameter SIP Application - RFC 4740
User-Authorization-Answer	UAA	283	Diameter SIP Application - RFC 4740
Server-Assignment-Request	SAR	284	Diameter SIP Application - RFC 4740
Server-Assignment-Answer	SAA	284	Diameter SIP Application - RFC 4740
Location-Info-Request	LIR	285	Diameter SIP Application - RFC 4740
Location-Info-Answer	LIA	285	Diameter SIP Application - RFC 4740
Multimedia-Auth-Request	MAR	286	Diameter SIP Application - RFC 4740
Multimedia-Auth-Answer	MAA	286	Diameter SIP Application - RFC 4740
Registration-Termination-Request	RTR	287	Diameter SIP Application - RFC 4740
Registration-Termination-Answer	RTA	287	Diameter SIP Application - RFC 4740
Push-Profile-Request	PPR	288	Diameter SIP Application - RFC 4740
Push-Profile-Answer	PPA	288	Diameter SIP Application - RFC 4740
User-Authorization-Request	UAR	300	Diameter base (3GPP) RFC 3589
User-Authorization-Answer	UAA	300	Diameter base (3GPP) RFC 3589
Server-Assignment-Request	SAR	301	Diameter base (3GPP) RFC 3589
Server-Assignment-Answer	SAA	301	Diameter base (3GPP) RFC 3589
Location-Info-Request	LIR	302	Diameter base (3GPP) RFC 3589
Location-Info-Answer	LIA	302	Diameter base (3GPP) RFC 3589
Multimedia-Auth-Request	MAR	303	Diameter base (3GPP) RFC 3589
Multimedia-Auth-Answer	MAA	303	Diameter base (3GPP) RFC 3589
Registration-Termination-Request	RTR	304	Diameter base (3GPP) RFC 3589
Registration-Termination-Answer	RTA	304	Diameter base (3GPP) RFC 3589
Push-Profile-Request	PPR	305	Diameter base (3GPP) RFC 3589
Push-Profile-Answer	PPA	305	Diameter base (3GPP) RFC 3589
User-Data-Request	UDR	306	Diameter base (3GPP) RFC 3589
User-Data-Answer	UDA	306	Diameter base (3GPP) RFC 3589
Profile-Update-Request	PUR	307	Diameter base (3GPP) RFC 3589
Profile-Update-Answer	PUA	307	Diameter base (3GPP) RFC 3589
Subscribe-Notifications-Request	SNR	308	Diameter base (3GPP) RFC 3589
Subscribe-Notifications-Answer	SNA	308	Diameter base (3GPP) RFC 3589
Push-Notification-Request	PNR	309	Diameter base (3GPP) RFC 3589
Push-Notification-Answer	PNA	309	Diameter base (3GPP) RFC 3589
Bootstrapping-Info-Request	BIR	310	Diameter base (3GPP) RFC 3589
Bootstrapping-Info-Answer	BIA	310	Diameter base (3GPP) RFC 3589
Message-Process-Request	MPR	311	Diameter base (3GPP) RFC 3589
Message-Process-Answer	MPA	311	Diameter base (3GPP) RFC 3589
Update-Location-Request	ULR	316	3GPP TS 29.272 [RFC 5516]
Update-Location-Answer	ULA	316	3GPP TS 29.272 [RFC 5516]
Cancel-Location-Request	CLR	317	3GPP TS 29.272 [RFC 5516]
Cancel-Location-Answer	CLA	317	3GPP TS 29.272 [RFC 5516]
Authentication-Information-Request	AIR	318	3GPP TS 29.272 [RFC 5516]
Authentication-Information-Answer	AIA	318	3GPP TS 29.272 [RFC 5516]
Insert-Subscriber-Data-Request	IDR	319	3GPP TS 29.272 [RFC 5516]
Insert-Subscriber-Data-Answer	IDA	319	3GPP TS 29.272 [RFC 5516]
Delete-Subscriber-Data-Request	DSR	320	3GPP TS 29.272 [RFC 5516]
Delete-Subscriber-Data-Answer	DSA	320	3GPP TS 29.272 [RFC 5516]
Purge-UE-Request	PER	321	3GPP TS 29.272 [RFC 5516]
Purge-UE-Answer	PEA	321	3GPP TS 29.272 [RFC 5516]
Notify-Request	NR	323	3GPP TS 29.272 [RFC 5516]
Notify-Answer	NA	323	3GPP TS 29.272 [RFC 5516]
Provide-Location-Request	PLR	8388620	3GPP-LCS-SLg (Application-ID 16777255)
Provide-Location-Answer	PLA	8388620	3GPP-LCS-SLg (Application-ID 16777255)
Routing-Info-Request	RIR	8388622	3GPP-LCS-SLh (Application-ID 16777291)
Routing-Info-Answer	RIA	8388622	3GPP-LCS-SLh (Application-ID 16777291)
AA-Mobile-Node-Request	AMR	260	Diameter Mobile IPv4 - RFC 4004
AA-Mobile-Node-Answer	AMA	260	Diameter Mobile IPv4 - RFC 4004
Home-Agent-MIP-Request	HAR	262	Diameter Mobile IPv4 - RFC 4004
Home-Agent-MIP-Answer	HAA	262	Diameter Mobile IPv4 - RFC 4004
Configuration-Information-Request	CIR	8388718	S6t per 3GPP TS 29.336
Configuration-Information-Answer	CIA	8388718	S6t per 3GPP TS 29.336
Reporting-Information-Request	RIR	8388719	S6t per 3GPP TS 29.336
Reporting-Information-Answer	RIA	8388719	S6t per 3GPP TS 29.336
NIDD-Information-Request	NIR	8388726	S6t per 3GPP TS 29.336
NIDD-Information-Answer	NIA	8388726	S6t per 3GPP TS 29.336

Application-ID

Application-ID is used to identify for which Diameter application the message is applicable. The application can be an authentication application, an accounting application, or a vendor-specific application.

Diameter agents conforming to a certain Diameter extension publicize its support by including a specific value of in the Auth-Application-Id Attribute of the Capabilities-Exchange-Request (CER) and Capabilities-Exchange-Answer (CEA) command.

The value of the Application-ID field in the header is the same as any relevant Application-Id AVPs contained in the message. For instance, the value of the Application-ID and of the Auth-Application-Id Attribute in the Credit-Control-Request (CCR) and Credit-Control-Answer (CCA) Command for the Diameter Credit-Control Application is 4.^[4]

Application-ID	Abbr.	Full name	Usage
0	Base	Diameter Common Messages	Diameter protocol association establishment/teardown/maintenance
16777216	Cx/Dx	3GPP Cx/Dx	IMS I/S-CSCF to HSS interface
16777217	Sh	3GPP Sh	VoIP/IMS SIP Application Server to HSS interface
16777236	Rx	3GPP Rx	Policy and charging control
16777238	Gx	3GPP Gx	Policy and charging control
16777251	S6a/S6d	3GPP S6a/S6d	LTE Roaming signaling
16777252	S13	3GPP 13	Interface between EIR and MME
16777255	SLg	3GPP LCS SLg	Location services
16777345	S6t	3GPP S6t	Interface between SCEF and HSS

Hop-by-Hop Identifier

The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in network byte order) that is used to match the requests with their answers as the same value in the request is used in the response.

The Diameter protocol requires that relaying and proxying agents maintain transaction state, which is used for failover purposes. Transaction state implies that upon forwarding a request, its Hop-by-Hop Identifier is saved; the field is replaced with a locally unique identifier, which is restored to its original value when the corresponding answer is received. The request's state is released upon receipt of the answer. Received answers that do not match a known Hop-by-Hop Identifier are ignored by the Diameter agent.

In case of redirecting agents, the Hop-by-Hop Identifier is maintained in the header as the Diameter agent responds with an answer message.

End-to-End Identifier

The End-to-End Identifier is an unsigned 32-bit integer field (in network byte order) that is used to detect duplicate messages along with the combination of the Origin-Host AVP.

When creating a request, the End-to-End Identifier is set to a locally unique value. The End-to-End Identifier is not modified by Diameter agents of any kind, and the same value in the corresponding request is used in the answer.

Attribute–Value Pairs (AVP)

AVP Header
Bit offset	`0`	`1`	`2`	`8`
0	AVP code
32	`V`	`M`	`P`	AVP length
64	vendor ID (optional)
96 ...	data ...

For simplicity, AVP Flag "V" bit Means Vendor Specific; "M" bit means Mandatory; "P" bit means Protected.

The "V" bit, known as the Vendor-Specific bit, indicates whether the optional Vendor-ID field is present in the AVP header. When set the AVP Code belongs to the specific vendor code address space.

The "M" bit, known as the Mandatory bit, indicates whether support of the AVP is required. If an AVP with the "M" bit set is received by a Diameter client, server, proxy, or translation agent and either the AVP or its value is unrecognized, the message must be rejected. Diameter Relay and redirect agents must not reject messages with unrecognized AVPs.

The "P" bit indicates the need for encryption for end-to-end security.

Attribute-Name	Code	Data Type
Acct-Interim-Interval	85	Unsigned32
Accounting-Realtime-Required	483	Enumerated
Acct-Multi-Session-Id	50	UTF8String
Accounting-Record-Number	485	Unsigned32
Accounting-Record-Type	480	Enumerated
Accounting-Session-Id	44	OctetString
Accounting-Sub-Session-Id	287	Unsigned64
Acct-Application-Id	259	Unsigned32
Auth-Application-Id	258	Unsigned32
Auth-Request-Type	274	Enumerated
Authorization-Lifetime	291	Unsigned32
Auth-Grace-Period	276	Unsigned32
Auth-Session-State	277	Enumerated
Re-Auth-Request-Type	285	Enumerated
Class	25	OctetString
Destination-Host	293	DiamIdent
Destination-Realm	283	DiamIdent
Disconnect-Cause	273	Enumerated
E2E-Sequence	300	Grouped
Error-Message	281	UTF8String
Error-Reporting-Host	294	DiamIdent
Event-Timestamp	55	Time
Experimental-Result	297	Grouped
Experimental-Result-Code	298	Unsigned32
Failed-AVP	279	Grouped
Firmware-Revision	267	Unsigned32
Host-IP-Address	257	Address
Inband-Security-Id	299	Unsigned32
Multi-Round-Time-Out	272	Unsigned32
Origin-Host	264	DiamIdent
Origin-Realm	296	DiamIdent
Origin-State-Id	278	Unsigned32
Product-Name	269	UTF8String
Proxy-Host	280	DiamIdent
Proxy-Info	284	Grouped
Proxy-State	33	OctetString
Redirect-Host	292	DiamURI
Redirect-Host-Usage	261	Enumerated
Redirect-Max-Cache-Time	262	Unsigned32
Result-Code	268	Unsigned32
Route-Record	282	DiamIdent
Session-Id	263	UTF8String
Session-Timeout	27	Unsigned32
Session-Binding	270	Unsigned32
Session-Server-Failover	271	Enumerated
Supported-Vendor-Id	265	Unsigned32
Termination-Cause	295	Enumerated
User-Name	1	UTF8String
Vendor-Id	266	Unsigned32
Vendor-Specific-Application-Id	260	Grouped

State machines

The RFC 3588 defines a core state machine for maintaining connections between peers and processing messages. This is part of the basic protocol functionality and all stacks should support it and as such abstract from the connectivity related operations.

Peer State Machine Part 1
Peer State Machine Part 2

Additionally, application specific state machines can be introduced either later or at a higher abstraction layer. The RFC 3588 defines an authorization and an accounting state machine.

Diameter Authorization State Machines (Client)
Diameter Authorization State Machines (Server)
Diameter Accounting State Machines (Client)
Diameter Accounting State Machines (Server)

Message flows

The communication between two diameter peers starts with the establishment of a transport connection (TCP or SCTP). The initiator then sends a Capabilities-Exchange-Request (CER) to the other peer, which responds with a Capabilities-Exchange-Answer (CEA). For RFC3588 compliant peers TLS (Transport Layer Security) may optionally be negotiated. For RFC6733 compliant peers TLS negotiation may optionally happen before the CER/CEA.

The connection is then ready for exchanging application messages.

If no messages have been exchanged for some time either side may send a Device-Watchdog-Request (DWR) and the other peer must respond with Device-Watchdog-Answer.

Either side may terminate the communication by sending a Disconnect-Peer-Request (DPR) which the other peer must respond to with Disconnect-Peer-Answer. After that the transport connection can be disconnected.

RFCs

The Diameter protocol is currently defined in the following IETF RFCs: Obsolete RFCs are indicated with strikethrough text.

#	Title	Date published	Obsoleted by
~~RFC 3588~~	~~Diameter Base Protocol.~~	~~September 2003~~	RFC 6733
RFC 3589	Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5.	September 2003
RFC 4004	Diameter Mobile IPv4 Application.	August 2005
~~RFC 4005~~	~~Diameter Network Access Server Application.~~	~~August 2005~~	RFC 7155
~~RFC 4006~~	~~Diameter Credit-Control Application.~~	~~August 2005~~	RFC 8506
RFC 4072	Diameter Extensible Authentication Protocol (EAP) Application.	August 2005
RFC 4740	Diameter Session Initiation Protocol (SIP) Application. M.	November 2006
RFC 5224	Diameter Policy Processing Application.	March 2008
RFC 5431	Diameter ITU-T Rw Policy Enforcement Interface Application.	March 2009
RFC 5447	Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction.	February 2009
RFC 5516	Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS).	April 2009
RFC 5624	Quality of Service Parameters for Usage with Diameter.	August 2009
~~RFC 5719~~	~~Updated IANA Considerations for Diameter Command Code Allocations.~~	~~January 2010~~	RFC 6733
RFC 6733	Diameter Base Protocol.	October 2012
RFC 6737	The Diameter Capabilities Update Application.	October 2012
RFC 7155	Diameter Network Access Server Application.	April 2014
RFC 8506	Diameter Credit-Control Application	March 2019

Related Research Articles

The Dynamic Host Configuration Protocol (DHCP) is a network management protocol used on Internet Protocol (IP) networks for automatically assigning IP addresses and other communication parameters to devices connected to the network using a client–server architecture.

HTTP is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.

The Internet Control Message Protocol (ICMP) is a supporting protocol in the Internet protocol suite. It is used by network devices, including routers, to send error messages and operational information indicating success or failure when communicating with another IP address. For example, an error is indicated when a requested service is not available or that a host or router could not be reached. ICMP differs from transport protocols such as TCP and UDP in that it is not typically used to exchange data between systems, nor is it regularly employed by end-user network applications.

In computing, the Post Office Protocol (POP) is an application-layer Internet standard protocol used by e-mail clients to retrieve e-mail from a mail server. Today, POP version 3 (POP3) is the most commonly used version. Together with IMAP, it is one of the most common protocols for email retrieval.

The Real-time Transport Protocol (RTP) is a network protocol for delivering audio and video over IP networks. RTP is used in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications including WebRTC, television services and web-based push-to-talk features.

The Simple Mail Transfer Protocol (SMTP) is an Internet standard communication protocol for electronic mail transmission. Mail servers and other message transfer agents use SMTP to send and receive mail messages. User-level email clients typically use SMTP only for sending messages to a mail server for relaying, and typically submit outgoing email to the mail server on port 587 or 465 per RFC 8314. For retrieving messages, IMAP is standard, but proprietary servers also often implement proprietary protocols, e.g., Exchange ActiveSync.

The Session Initiation Protocol (SIP) is a signaling protocol used for initiating, maintaining, and terminating communication sessions that include voice, video and messaging applications. SIP is used in Internet telephony, in private IP telephone systems, as well as mobile phone calling over LTE (VoLTE).

In computer networking, the User Datagram Protocol (UDP) is one of the core communication protocols of the Internet protocol suite used to send messages to other hosts on an Internet Protocol (IP) network. Within an IP network, UDP does not require prior communication to set up communication channels or data paths.

Simple Network Management Protocol (SNMP) is an Internet Standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behavior. Devices that typically support SNMP include cable modems, routers, switches, servers, workstations, printers, and more.

In computing, Internet Protocol Security (IPsec) is a secure network protocol suite that authenticates and encrypts packets of data to provide secure encrypted communication between two computers over an Internet Protocol network. It is used in virtual private networks (VPNs).

Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized authentication, authorization, and accounting (AAA) management for users who connect and use a network service. RADIUS was developed by Livingston Enterprises in 1991 as an access server authentication and accounting protocol. It was later brought into IEEE 802 and IETF standards.

In computing, Internet Key Exchange is the protocol used to set up a security association (SA) in the IPsec protocol suite. IKE builds upon the Oakley protocol and ISAKMP. IKE uses X.509 certificates for authentication ‒ either pre-shared or distributed using DNS ‒ and a Diffie–Hellman key exchange to set up a shared session secret from which cryptographic keys are derived. In addition, a security policy for every peer which will connect must be manually maintained.

In computer networking, Layer 2 Tunneling Protocol (L2TP) is a tunneling protocol used to support virtual private networks (VPNs) or as part of the delivery of services by ISPs. It uses encryption ('hiding') only for its own control messages, and does not provide any encryption or confidentiality of content by itself. Rather, it provides a tunnel for Layer 2, and the tunnel itself may be passed over a Layer 3 encryption protocol such as IPsec.

In computer networking, the Datagram Congestion Control Protocol (DCCP) is a message-oriented transport layer protocol. DCCP implements reliable connection setup, teardown, Explicit Congestion Notification (ECN), congestion control, and feature negotiation. The IETF published DCCP as RFC 4340, a proposed standard, in March 2006. RFC 4336 provides an introduction.

Extensible Authentication Protocol (EAP) is an authentication framework frequently used in network and internet connections. It is defined in RFC 3748, which made RFC 2284 obsolete, and is updated by RFC 5247. EAP is an authentication framework for providing the transport and usage of material and parameters generated by EAP methods. There are many methods defined by RFCs, and a number of vendor-specific methods and new proposals exist. EAP is not a wire protocol; instead it only defines the information from the interface and the formats. Each protocol that uses EAP defines a way to encapsulate by the user EAP messages within that protocol's messages.

AAA refers to Authentication, Authorization and Accounting.

Reliable Server Pooling (RSerPool) is a computer protocol framework for management of and access to multiple, coordinated (pooled) servers. RSerPool is an IETF standard, which has been developed by the IETF RSerPool Working Group and documented in RFC 5351, RFC 5352, RFC 5353, RFC 5354, RFC 5355 and RFC 5356.

The Stream Control Transmission Protocol (SCTP) has a simpler basic packet structure than TCP. Each consists of two basic sections:

The common header, which occupies the first 12 bytes. In the adjacent diagram, this header is highlighted in blue.
The data chunks, which form the remaining portion of the packet. In the diagram, the first chunk is highlighted in green and the last of N chunks (Chunk N) is highlighted in red. There are several types, including payload data and different control messages.

Kerberized Internet Negotiation of Keys (KINK) is a protocol defined in RFC 4430 used to set up an IPsec security association (SA), similar to Internet Key Exchange (IKE), utilizing the Kerberos protocol to allow trusted third parties to handle authentication of peers and management of security policies in a centralized fashion.

The Stream Control Transmission Protocol (SCTP) is a computer networking communications protocol in the transport layer of the Internet protocol suite. Originally intended for Signaling System 7 (SS7) message transport in telecommunication, the protocol provides the message-oriented feature of the User Datagram Protocol (UDP), while ensuring reliable, in-sequence transport of messages with congestion control like the Transmission Control Protocol (TCP). Unlike UDP and TCP, the protocol supports multihoming and redundant paths to increase resilience and reliability.

References

↑ Pat R. Calhoun, Glen Zorn, and Ping Pan (February 2001). "DIAMETER Framework Document". Ietf Datatracker. IETF . Retrieved 30 April 2009.{{cite news}}: CS1 maint: multiple names: authors list (link)
↑ Naman Mehta (20 March 2009). "Introduction to Diameter Protocol - What is Diameter Protocol?". Sun Microsystems. Archived from the original on 4 July 2011. Retrieved 30 April 2009.
↑ Arkko, J.; Loughney, J. (2012). Fajardo, V; Zorn, G (eds.). "RFC 6733 - Diameter Base Protocol". Proposed Standard. Standards Track. doi: 10.17487/RFC6733 . ISSN 2070-1721 . Retrieved 12 October 2014.
↑ Hakala, H.; Mattila, L.; Stura, M.; Loughney, J. (2005). "RFC 4006 - Diameter Credit-Control Application". Proposed Standard. Standards Track. doi: 10.17487/RFC4006 .

External links

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.

[1] Pat R. Calhoun, Glen Zorn, and Ping Pan (February 2001). "DIAMETER Framework Document". Ietf Datatracker. IETF . Retrieved 30 April 2009.{{cite news}}: CS1 maint: multiple names: authors list (link)

[2] Naman Mehta (20 March 2009). "Introduction to Diameter Protocol - What is Diameter Protocol?". Sun Microsystems. Archived from the original on 4 July 2011. Retrieved 30 April 2009.

[rfc6733-3] Arkko, J.; Loughney, J. (2012). Fajardo, V; Zorn, G (eds.). "RFC 6733 - Diameter Base Protocol". Proposed Standard. Standards Track. doi: 10.17487/RFC6733 . ISSN 2070-1721 . Retrieved 12 October 2014.

[rfc4006-4] Hakala, H.; Mattila, L.; Stura, M.; Loughney, J. (2005). "RFC 4006 - Diameter Credit-Control Application". Proposed Standard. Standards Track. doi: 10.17487/RFC4006 .

[1]

[2]

[3]

[4]

v t e Authentication
Authentication APIs	BSD Authentication (BSD Auth) eAuthentication (eAuth) Generic Security Services API (GSSAPI) Java Authentication and Authorization Service (JAAS) Pluggable Authentication Modules (PAM) Simple Authentication and Security Layer (SASL) Security Support Provider Interface (SSPI) XCert Universal Database API (XUDA)
Authentication protocols	ACF2 Authentication and Key Agreement (AKA) CAVE-based authentication Challenge-Handshake Authentication Protocol (CHAP) MS-CHAP Central Authentication Service (CAS) CRAM-MD5 Diameter Extensible Authentication Protocol (EAP) Host Identity Protocol (HIP) IndieAuth Kerberos LAN Manager NT LAN Manager (NTLM) OAuth OpenID OpenID Connect (OIDC) Password-authenticated key agreement protocols Password Authentication Protocol (PAP) Protected Extensible Authentication Protocol (PEAP) Remote Access Dial In User Service (RADIUS) Resource Access Control Facility (RACF) Secure Remote Password protocol (SRP) TACACS Woo–Lam
Category Commons