1. 简介

1. 简介

诸如 TACACS [RFC1492] 和 RADIUS [RFC2865] 等认证、授权和计费（AAA）协议最初被部署用于提供拨号 PPP [RFC1661] 和终端服务器访问。随着时间的推移，许多新的接入技术需要 AAA 支持，AAA 网络的规模和复杂性不断增长，AAA 也被用于新的应用（例如 IP 语音）。这导致了对 AAA 协议的新需求。

AAA 协议的网络接入需求总结在 Aboba 等人的 [RFC2989] 中。这些需求包括：

故障转移

[RFC2865] 未定义故障转移机制，因此故障转移行为在不同实现之间有所不同。为了提供定义明确的故障转移行为，Diameter 支持应用层确认，并定义了故障转移算法和相关的状态机。

传输层安全

RADIUS [RFC2865] 定义了一种应用层身份验证和完整性方案，该方案仅要求用于响应数据包。虽然 [RFC2869] 定义了额外的身份验证和完整性机制，但仅在可扩展身份验证协议（EAP）[RFC3748] 会话期间才需要使用。虽然支持属性隐藏，但 [RFC2865] 不提供对逐包保密性的支持。在计费方面，[RFC2866] 假设重放保护由后端计费服务器提供，而不是在协议本身内提供。

虽然 [RFC3162] 定义了 IPsec 与 RADIUS 的使用，但不要求支持 IPsec。为了提供传输层安全的通用支持，并实现域内和域间 AAA 部署，Diameter 提供了对 TLS/TCP 和 DTLS/SCTP 的支持。安全性在第 13 节中讨论。

可靠传输

RADIUS 运行在 UDP 上，并且未定义重传行为；因此，可靠性在不同实现之间有所不同。如 [RFC2975] 中所述，这在计费中是一个主要问题，其中数据包丢失可能直接转化为收入损失。为了提供定义明确的传输行为，Diameter 运行在可靠传输机制（TCP、流控制传输协议（SCTP））上，如 [RFC3539] 中定义。

代理支持

RADIUS 不提供对代理的显式支持，包括代理服务器、重定向和中继。由于未定义预期行为，因此在不同实现之间有所不同。Diameter 明确定义了代理行为；这在第 2.8 节中描述。

服务器发起的消息

虽然 RADIUS [RFC5176] 中定义了服务器发起的消息，但支持是可选的。这使得在异构部署中实现诸如主动断开连接或按需重新认证/重新授权等功能变得困难。为了解决这个问题，Diameter 中强制支持服务器发起的消息。

过渡支持

虽然 Diameter 不与 RADIUS 共享公共协议数据单元（PDU），但在实现与 RADIUS 的向后兼容性方面已经付出了相当大的努力，以便两种协议可以部署在同一网络中。最初，预计 Diameter 将部署在新的网络设备中，以及部署在能够实现传统 RADIUS 设备与 Diameter 代理之间通信的网关中。这种能力使得可以通过添加同时支持 RADIUS 和 Diameter 的网关或服务器，将 Diameter 支持添加到传统网络中。

除了满足上述需求外，Diameter 还提供对以下内容的支持：

能力协商

RADIUS 不支持错误消息、能力协商或属性的强制/非强制标志。由于 RADIUS 客户端和服务器不了解彼此的能力，它们可能无法成功协商双方都可接受的服务，或者在某些情况下，甚至无法知道已实现了什么服务。Diameter 包括对错误处理（第 7 节）、能力协商（第 5.3 节）和强制/非强制属性值对（AVP）（第 4.1 节）的支持。

对等点发现和配置

RADIUS 实现通常要求手动配置服务器或客户端的名称或地址以及相应的共享密钥。这导致了巨大的管理负担，并产生了重用 RADIUS 共享密钥的诱惑，如果请求认证器不是全局且时间上唯一的（如 [RFC2865] 中要求），这可能导致重大的安全漏洞。通过 DNS，Diameter 能够动态发现对等点（参见第 5.2 节）。通过传输层安全实现动态会话密钥的派生。

随着时间的推移，网络接入服务器（NAS）设备的能力已大幅提高。因此，虽然 Diameter 是一个比 RADIUS 复杂得多的协议，但在嵌入式设备中实现它仍然是可行的。

1.1. Diameter 协议

Diameter 基础协议提供以下功能：

• 交换消息和传递 AVP 的能力
• 能力协商
• 错误通知
• 通过添加新的应用、命令和 AVP 实现的可扩展性，[RFC2989] 中要求
• 应用所需的基本服务，例如处理用户会话或计费

协议传递的所有数据均采用 AVP 的形式。其中一些 AVP 值由 Diameter 协议本身使用，而其他值则传递与使用 Diameter 的特定应用相关的数据。AVP 可以任意添加到 Diameter 消息中，唯一的限制是必须满足命令代码格式（CCF）规范（第 3.2 节）。基础 Diameter 协议使用 AVP 来支持以下必需功能：

• 传输用户身份验证信息，以使 Diameter 服务器能够对用户进行身份验证
• 在客户端和服务器之间传输特定于服务的授权信息，允许对等点决定是否应授予用户的访问请求
• 交换资源使用信息，可用于计费目的、容量规划等
• 通过服务器层次结构路由、中继、代理和重定向 Diameter 消息

Diameter 基础协议满足 AAA 协议的最低要求，如 [RFC2989] 所指定。基础协议可以单独用于仅计费目的，也可以与 Diameter 应用一起使用，例如移动 IPv4 [RFC4004] 或网络接入 [RFC4005]。基础协议也可以通过添加新命令或 AVP 扩展用于新应用。Diameter 的最初重点是网络接入和计费应用。许多应用使用的真正通用的 AAA 协议可能会提供 Diameter 未提供的功能。因此，新应用的设计者在使用 Diameter 之前了解他们的需求是至关重要的。有关 Diameter 应用的更多信息，请参见第 1.3.4 节。

任何节点都可以发起请求。从这个意义上说，Diameter 是一种对等协议。在本文档中，Diameter 客户端是网络边缘执行访问控制的设备，例如网络接入服务器（NAS）或外地代理（FA）。Diameter 客户端生成 Diameter 消息以请求对用户的身份验证、授权和计费服务。Diameter 代理是不提供本地用户身份验证或授权服务的节点；代理包括代理服务器、重定向和中继代理。Diameter 服务器执行用户的身份验证和/或授权。Diameter 节点可以在充当某些请求的代理的同时充当其他请求的服务器。

Diameter 协议还支持服务器发起的消息，例如中止向特定用户提供服务的请求。

1.1.1. 文档集描述

Diameter 规范由基础协议规范（本文档）和传输配置文件 [RFC3539] 的更新版本组成。本文档废弃了 RFC 3588 和 RFC 5719。本文档中包含的基础协议更新摘要可在第 1.1.3 节中找到。

本文档定义了 AAA 的基础协议规范，其中包括对计费的支持。还有无数的应用文档描述了使用此基础规范进行身份验证、授权和计费的应用。这些应用文档指定了如何在其应用的上下文中使用 Diameter 协议。

传输配置文件文档 [RFC3539] 讨论了 AAA 协议出现的传输层问题以及如何克服这些问题的建议。本文档还定义了 Diameter 故障转移算法和状态机。

"基于用户名和域的 Diameter 请求路由说明" [RFC5729] 定义了如何根据用户名 AVP（属性值对）的内容路由请求的特定行为。

1.1.2. 本文档中使用的约定

本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按照 [RFC2119] 中的描述进行解释。

1.1.3. 与 RFC 3588 的变化

本文档废弃了 RFC 3588，但与该文档完全向后兼容。本文档中引入的更改侧重于修复 Diameter（RFC 3588）实现期间出现的问题。以下给出了一些主要更改的概述。

• 弃用了 Inband-Security AVP 用于协商传输层安全（TLS）[RFC5246] 的使用。人们普遍认为，通过 Inband-Security AVP 引导 TLS 会产生某些安全风险，因为它不能完全保护 CER/CEA（能力交换请求/能力交换应答）中携带的信息。此版本的 Diameter 采用了定义公知安全端口的通用方法，对等点在通过 TLS/TCP 和 DTLS/SCTP 通信时应使用该端口。这种新方法增强了现有的带内安全协商，但并未完全取代它。旧方法因向后兼容性原因而保留。

• 弃用了在开放状态下交换 CER/CEA 消息。此功能在 RFC 3588 的对等状态机表中暗示，但在该文档的其他地方没有明确定义。随着本文档工作的进展，很明显，CER/CEA 消息中应用 ID AVP 的多重含义和使用（以及消息本身）被视为对 Diameter 可扩展性规则的滥用，因此需要简化。在开放状态下的能力交换已在单独的规范 [RFC6737] 中重新引入，该规范明确定义了此功能的新命令。

• 简化了安全要求。交换 Diameter 消息使用安全传输仍然是强制性的。但是，TLS/TCP 和 DTLS/SCTP 已成为保护 Diameter 的主要方法，IPsec 作为次要替代方案。详见第 13 节。对端到端安全框架（E2E-Sequence AVP 和 AVP 标头中的 'P' 位）的支持也已弃用。

• 更改了 Diameter 可扩展性。这包括对 Diameter 可扩展性描述（第 1.3 节等）的修复，以更好地帮助 Diameter 应用设计者；此外，新规范放宽了关于为特定于供应商的使用分配命令代码的政策。

• 澄清了应用 ID 的使用。阐明应用 ID 信息的正确使用，该信息可以在 Diameter 消息中的多个位置找到。这包括关联消息标头和 AVP 中找到的应用 ID。这些更改还明确指定了用于特定基础协议消息（ASR/ASA、STR/STA）的正确应用 ID 值，并阐明了 Vendor-Specific-Application-Id 的内容和使用。

• 澄清了路由修复。本文档更清楚地指定了可用于制定一般路由决策的信息（AVP 和应用 ID）。还添加了当通过重定向找到多个路由条目时重定向路由标准优先级的规则（参见第 6.13 节）。

• 简化了 Diameter 对等点发现。Diameter 发现过程现在仅支持广泛使用的发现方案；其余的已被弃用（详见第 5.2 节）。

本文档中还引入了许多其他杂项修复，这些修复可能不被认为是重要的，但无论如何都有价值。例如，删除过时的类型、修复状态机、澄清选举过程、消息验证、修复 Failed-AVP 和 Result-Code AVP 值等。在本文档发布之前针对 RFC 3588 提交的所有勘误表都已得到解决。出于实际原因，此处未显示更改的完整列表。

1.2. 术语

AAA

认证、授权和计费。

ABNF

增强的巴科斯-诺尔范式 [RFC5234]。一种具有自己的正式语法和规则的元语言。它基于巴科斯-诺尔范式，用于定义双向通信协议中的消息交换。

计费（Accounting）

为容量规划、审计、计费或成本分配的目的收集资源使用信息的行为。

计费记录（Accounting Record）

计费记录表示用户在整个会话期间资源消耗的摘要。创建计费记录的计费服务器可以通过处理临时计费事件或来自服务同一用户的多个设备的计费事件来实现。

身份验证（Authentication）

验证实体（主体）身份的行为。

授权（Authorization）

确定是否允许请求实体（主体）访问资源（对象）的行为。

属性值对（Attribute-Value Pair，AVP）

Diameter 协议由标头和一个或多个属性值对（AVP）组成。AVP 包括标头，用于封装协议特定数据（例如，路由信息）以及身份验证、授权或计费信息。

命令代码格式（Command Code Format，CCF）

用于定义 Diameter 命令的 ABNF 的修改形式（参见第 3.2 节）。

Diameter 代理（Diameter Agent）

Diameter 代理是提供中继、代理、重定向或转换服务的 Diameter 节点。

Diameter 客户端（Diameter Client）

Diameter 客户端是支持 Diameter 客户端应用以及基础协议的 Diameter 节点。Diameter 客户端通常在位于网络边缘的设备中实现，并为该网络提供访问控制服务。Diameter 客户端的典型示例包括网络接入服务器（NAS）和移动 IP 外地代理（FA）。

Diameter 节点（Diameter Node）

Diameter 节点是实现 Diameter 协议并充当客户端、代理或服务器的主机进程。

Diameter 对等点（Diameter Peer）

共享直接 TCP 或 SCTP 传输连接的两个 Diameter 节点称为 Diameter 对等点。

Diameter 服务器（Diameter Server）

Diameter 服务器是处理特定域的身份验证、授权和计费请求的 Diameter 节点。就其本质而言，Diameter 服务器除了基础协议外还必须支持 Diameter 服务器应用。

下游（Downstream）

下游用于标识从归属服务器到 Diameter 客户端的特定 Diameter 消息的方向。

归属域（Home Realm）

归属域是用户与之保持账户关系的管理域。

归属服务器（Home Server）

为归属域提供服务的 Diameter 服务器。

临时计费（Interim Accounting）

临时计费消息提供用户会话期间使用情况的快照。通常，它被实现以便在设备重启或其他网络问题阻止传递会话摘要消息或会话记录的情况下提供用户会话的部分计费。

本地域（Local Realm）

本地域是向用户提供服务的管理域。管理域可以充当某些用户的本地域，同时是其他用户的归属域。

多会话（Multi-session）

多会话表示多个会话的逻辑链接。使用 Acct-Multi-Session-Id 跟踪多会话。多会话的示例是多链路 PPP 捆绑。捆绑的每条链路将是一个会话，而整个捆绑将是一个多会话。

网络接入标识符（Network Access Identifier）

网络接入标识符或 NAI [RFC4282] 在 Diameter 协议中用于提取用户的身份和域。身份用于在身份验证和/或授权期间识别用户，而域用于消息路由目的。

代理代理或代理（Proxy Agent or Proxy）

除了转发请求和响应外，代理还制定与资源使用和配置相关的策略决策。通常，这是通过跟踪 NAS 设备的状态来实现的。虽然代理通常不会在收到服务器响应之前响应客户端请求，但它们可能会在违反策略的情况下发起拒绝消息。因此，代理需要了解通过它们的消息的语义，并且它们可能不支持所有 Diameter 应用。

域（Realm）

NAI 中紧跟在 '@' 字符后面的字符串。NAI 域名必须是唯一的，并且基于 DNS 命名空间的管理。Diameter 使用域（也被宽泛地称为域）来确定消息是否可以在本地满足，或者是否必须路由或重定向。在 RADIUS 中，域名不一定基于 DNS 命名空间，但可能独立于它。

实时计费（Real-Time Accounting）

实时计费涉及在定义的时间窗口内处理资源使用信息。通常，施加时间约束是为了限制财务风险。Diameter 信用控制应用 [RFC4006] 是定义实时计费功能的应用示例。

中继代理或中继（Relay Agent or Relay）

中继根据路由相关的 AVP 和路由表条目转发请求和响应。由于中继不制定策略决策，因此它们不检查或更改非路由 AVP。因此，中继从不发起消息，不需要了解消息或非路由 AVP 的语义，并且能够处理任何 Diameter 应用或消息类型。由于中继基于路由 AVP 和域转发表中的信息做出决策，因此它们不保留 NAS 资源使用或正在进行的会话的状态。

重定向代理（Redirect Agent）

重定向代理不是在客户端和服务器之间转发请求和响应，而是将客户端引用到服务器并允许它们直接通信。由于重定向代理不在转发路径中，因此它们不会更改客户端和服务器之间传输的任何 AVP。重定向代理不发起消息，并且能够处理任何消息类型，尽管它们可能被配置为仅重定向某些类型的消息，同时充当其他类型的中继或代理代理。与中继代理一样，重定向代理不保留关于会话或 NAS 资源的状态。

会话（Session）

会话是致力于特定活动的相关事件进展。Diameter 应用文档提供了关于会话何时开始和结束的指导。具有相同 Session-Id 的所有 Diameter 数据包都被视为同一会话的一部分。

有状态代理（Stateful Agent）

有状态代理是通过跟踪所有授权的活动会话来维护会话状态信息的代理。每个授权会话都绑定到特定服务，并且其状态被视为处于活动状态，直到另行通知或到期。

子会话（Sub-session）

子会话表示提供给给定会话的不同服务（例如，QoS 或数据特征）。这些服务可能同时发生（例如，在同一会话期间同时进行语音和数据传输）或串行发生。使用 Accounting-Sub-Session-Id 跟踪会话中的这些变化。

事务状态（Transaction State）

Diameter 协议要求代理维护事务状态，该状态用于故障转移目的。事务状态意味着在转发请求时，保存跳到跳标识符；该字段被替换为本地唯一标识符，当收到相应的应答时，该标识符被恢复为其原始值。请求的状态在收到应答时释放。无状态代理是仅维护事务状态的代理。

转换代理（Translation Agent）

转换代理（图 4 中的 TLA）是在 Diameter 和另一种 AAA 协议（例如 RADIUS）之间执行协议转换的有状态 Diameter 节点。

上游（Upstream）

上游用于标识从 Diameter 客户端到归属服务器的特定 Diameter 消息的方向。

用户（User）

请求或使用某些资源的实体或设备，Diameter 客户端已为其生成请求。

1.3. 可扩展性方法

Diameter 协议设计为可扩展，使用多种机制，包括：

• 定义新的 AVP 值
• 创建新的 AVP
• 创建新的命令
• 创建新的应用

从可扩展性的角度来看，Diameter 身份验证、授权和计费应用以相同的方式处理。

注意：协议设计者应尝试重用现有功能，即 AVP 值、AVP、命令和 Diameter 应用。重用简化了标准化和实现。为了避免潜在的互操作性问题，重要的是确保充分理解重用功能的语义。鉴于 Diameter 也可以将 RADIUS 属性作为 Diameter AVP 携带，这种重用考虑也适用于可能在 Diameter 应用中有用的现有 RADIUS 属性。

1.3.1. 定义新的 AVP 值

为了为 Diameter 基础协议中定义的 AVP 分配新的 AVP 值，IETF 需要批准描述 AVP 值的新 RFC。这些 AVP 值的 IANA 考虑因素在第 11.3 节中讨论。

其他 AVP 的 AVP 值分配由定义这些 AVP 的文档的 IANA 考虑因素指导。通常，为 RFC 中定义的 AVP 分配新值需要 IETF 审查 [RFC5226]，而特定于供应商的 AVP 的值可以由供应商分配。

1.3.2. 创建新的 AVP

正在定义的新 AVP 必须使用第 4.2 节或第 4.3 节中列出的数据类型之一。如果已经定义了适当的派生数据类型，则应使用它而不是基本数据类型，以鼓励可重用性和良好的设计实践。

如果需要对 AVP 进行逻辑分组，并且给定命令中可能有多个"组"，则建议使用分组 AVP（参见第 4.4 节）。

创建新 AVP 可以通过多种方式进行。推荐的方法是在 IETF 批准的标准跟踪 RFC 中定义新的通用 AVP。但是，如第 11.1.1 节所述，还有其他机制。

1.3.3. 创建新命令

当需要将 AVP（在 CCF 定义中指示为 {AVP} 的那些）添加到现有命令、从现有命令中删除或在现有命令中重新定义（例如，通过将必需的 AVP 更改为可选的 AVP）时，必须分配新的命令代码。

此外，如果命令的传输特性发生变化（例如，关于所需的往返次数），则必须注册新的命令代码。

如上所述，对命令的 CCF 的更改必须导致定义新的命令代码。这随后导致需要为将使用该新命令的任何应用定义新的 Diameter 应用。

命令代码的 IANA 考虑因素在第 3.1 节中讨论。

1.3.4. 创建新的 Diameter 应用

Diameter 应用可以定义新的命令代码、AVP 和相关语义。创建新的 Diameter 应用通常需要 IETF 批准的标准跟踪 RFC。详见第 11.2.1 节。