Diameter协议学习笔记一(协议介绍)

原文来自百度文库

http://wenku.baidu.com/view/bc91976127d3240c8447efec.html?re=view

一、摘要：

Diameter协议主要为应用程序提供认证、鉴权、计费框架，即AAA，并支持本地AAA和漫游场景下的AAA。

二、介绍：

AAA协议、例如TACACS、RADIUS起初是为了提供PPP及终端接入，随着Internet及新的接入技术的发展，包括无线、DSL、移动IP, 以太网路由、网络访问服务器（NAS）在复杂和密集性方面有所增强，这对AAA协议提出了新的要求。

例如，网络访问对AAA 协议提出的要求总结有以下这些：

· Failover（故障转移）

RADIUS协议没有定义failover机制，因此，failover的行为随着程序的实现不同而各异，为了提供一个明确定义的failover行为，Diameter支持应用层的应答，并定义failover的西装算法和偶联状态机。

· 传输层安全

RADIUS在定义了应用层的认证，但仅使用了响应包，RADEXT定义了另外的认证，但仅要求在EAP session中使用，且支持属性隐藏。RFC3162为RADIUS定义了IPsec，但对其支持并没有做要求，Diameter强制要求支持IPSec,TLS的支持可选择。

· 可靠传输

RADIUS运行在UDP上，且没有定义重传行为，所有，可靠性因实现不同而各异。Diameter运行在可靠的传输层（TCP, SCTP）上。

· 代理支持

RADIUS没有明确地规定支持agent，包括Proxies, Redirects, Relays。Diameter明确地定义了代理的行为。

· 服务器发起消息

RADIUS中对于服务器发起消息的支持是可选的，这就使用一些如主动断链、或者重新认证或重新鉴权等特性实现困难。服务器发起消息在Diameter中强制要求支持。

· 可审核性

RADIUS没有定义数据对象安全机制，结果，不受信任的代理可能修改属性或都包头，并且不会被检测出来，结合对能力协商机制的缺失，无法预期结果会发生什么。Diameter也没有定义数据对象安全机制，但支持能力协商。

· 转换支持

Diameter使用的通用协议数据单元(PDU)与RADIUS不同，但支持向前兼容RADIUS,所以两种协议可以部署在同一网络中。

· 能力协商

RADIUS不支持错误消息、能力协商、及表示属性强制/非强制的标志位。因此RADIUS的客户端和服务端不担心对方的能力，它们可能不会成功地协商一个相互接受的服务，或者在一些情况下，需要知道哪些服务对端已经实现，以上几点Diameter均支持。

· 对端发现及配置

RADIUS要求人工配置服务端或客户端的名称或地址，相应地增加了秘密的共享，带来管理和安全上的负担。通过DNS，Diameter可以动态发现对端，并通过传输层安全来保证。

· 漫游支持

RADIUS不提供对proxyr的明确支持，缺少可审核性、传输层安全，使得在漫游场景下容易引发安全问题，Diameter支持域内漫游、消息路由、可审核性、传输层安全特性，可提供可安全和可靠的漫游。

术语：

· AAA

认证、鉴权、计费

· Accounting（计费）

为能力计划制定、审计、账单、费用分配等目的而进行资源使用的信息的收集动作。

· Accounting Record (计费记录)

记录某个用户在整个会话期间资源消费的情况，

· Authentication(认证)

校验一个实体一致性的动作。

· Authorization(鉴权)

决定一个请求实体是否允许访问某项资源。

· AVP (属性值对)

Diameter消息由一个报文头后跟一个或多个Attribute-Value-Pairs(AVPs),一个AVP包含一个头用于协议细节数据（例如路由信息）。

· Broker (代理)

代理是一个用于AAA架构中的商业术语，可以是relay, proxy,或者redirect agent。

· Diameter Agent(Diameter 代理)

指一个提供relay、proxy、redirect或翻译服务的diameter结点。

· Diameter Client(Diameter 客户端)

为一个处于网络边缘的，提供访问控制的设备。如NAS。

· Diameter Node（Diameter 节点）

为一个实现了diameter协议的主机进程，其行为为客户端、代理、服务端之一。

· Diameter Peer (Diameter 对端)

为一个具有直连连接的diameter节点。

· Diameter Security Exchange (diameter 安全交换)

为一个进程，两个diameter节点可以通过它建立端到端的安全。

· Diameter Server(diameter 服务端)

用于处理指定域中认证、鉴权、计费请求。

· End-to-End Security (端到端安全)

TLS和IPSec提供逐跳的安全，当relays或proxy很复杂时，逐跳的安全不能保证全部的diameter用户会话，端到端安全为两个diameter节点间的安全，或者Agent间的，这种安全保证了整个dimeter传送路径上的安全。

· Home Realm（归属域）

为一个维护帐户关系的管理域。

· Interim accounting(临时计费)

一个临时计费消息提供一个用户会话的使用快照，通常为一个用户会话在设备重启或者网络问题出现时提供部分的计费。

· Local Realm（本地域）

一个提供服务的管理域。

· Multi-Sessin(多会话）

一个多会话表示多个会话的逻辑连接，多会话使用Acct-Multi-Session-Id来跟踪。

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

即NAI，用来在diameter协议中提取一个用户的标识及域。用于在认证中识别用户，域用来消息路由。

· Proxy Agent or Proxy (代理)

除传输请求和响应外，代理制定与资源有关的策略，通常用来完成NAS设备状态的跟踪，代理在收到一个服务端的响应前不会对客户端的请求进行应答。当策略被违反时，它们可能会生成一个拒绝消息。因此，代理需要理解通过它们传输的消息的语义，它们可能不支持所有的diameter应用。

· Realm(域)

在NAI中跟在@符号之后的字符串，NAI的域要求为唯一的，且为DNS域的分段，用于判断消息是否满足本地处理的条件，或者被路由或重定向。

· Real-time Accounting(实时计费)

它包含在一个限定的时间窗内处理资源使用的信息，时间限制通常用来限制风险。

· Relay Agent or Relay(中继代理或转播)

转播请求和响应基于路由相关的AVPs和路由表，中继不会制定策略，他们不会检查或更改非路由AVPs,因此，中继从不产生消息，不需要理解消息的语义或者非路由AVPs,可能会处理八种diameter应用或消息类型，因此，中继依据路由和域来做决定，并且不保存NAS资源使用的状态或会话。

· Redirect Agent(重定向代理)

与其在客户端和服务端间传递消息，重定向代理涉及客户端和服务端，并允许它们直接通信，所以重定向代理不出现在传输路径中，它们从不修改客户端和服务端传输的任何AVPs,也不产生消息，可以处理任何消息类型，尽管它们可能仅配置为重定向特定类型的消息，与Proxy代理相比，重定向代理不保存会话或NAS资源相关的状态。

· Security Association(安全偶联)

一个安全的偶联是指两个端点之间的diameter会话，此会话允许端点完整且可信地通信，包括中继和/或Proxy。

· Session（会话）

会话是指一个事件相关的活动。每个应用应该为会话的开始和结束提供指导，所有具有相同会话标识的diameter包被认为同一个会话的一部分。

· Sub-session(子会话)

一个子会话表示一个明确的服务（例如Qos）,这些服务可能同时或连续发生（例如同时产生的语音和同一会话中传输的数据）。此类会话由Accounting-Sub-Session-Id来跟踪。

· Transaction state(传输状态)

Diameter协议要求代理来维护传输状态，用于failover。传输状态暗指一个请求，逐跳标识被保存，且原来存储对应应答接收时的初始值字段被本地唯一标识符替代，当拒绝一个应答时请求的状态被释放。

· Translation Agent(传输代理)

是指为一个具有状态的dimaeter节点，用于在diameter和其它的AAA协议（如RADIUS）间进行翻译。

· Translation Connection(传输连接)

一个传输连接是指直接存在于两个diameter对端间的TCP或SCTP连接，或者说端到端连接。

· Upstream(上行）

用来标识一个特定的diameter消息从接入设备到归属服务器的传送方向。

· User(用户)

产生请求或使用某些资源的实体，支持diameter客户端产生一个请求。

· 链接和会话的区别：

链接为传输层概念，会话为应用层的概念，通过AVP Session-Id来标识，两者之前没有联系。如下图：

+--------+ +-------+ +--------+

+--------+ +-------+ +--------+

<----------> <---------->

peer connection A peer connection B

<----------------------------->

User session x

Figure 1: Diameter connections and sessions

· 对端表

用于消息传递和路由表全使用，包括以下信息：

1. Host标识：包括Origin-Host AVP，在CER/CEA消息中使用。

2. StatusT:对端实体的状态。

3. Static or Dynamic:指对端是静态配置的还是动态发现。

4. Expiration time:指使用动态发现机制时刷新超时的时长。

5. TLS Enablee: 与对端通信时是否使用TLS。

· 基于域名的路由表

1. 域名：用于查找路由表时使用的主键。

2. 应用程序标识：使用一个Vendor id和一个applicaiont id标识，其为路由表的第二主键。

3. Local Action:决定消息如何处理,有以下几个选项：

LOCAL:本地处理，不需要路由到下一个服务器。

RELAY:路由到下一跳，注意不修改任何非路由的AVP。

PROXY:路由到下一跳，注意可能会在消息中添加新的AVP。

REDIRECT:具有一个源diameter服务器的标识，且将消息返回给发送者。

4. 服务器标识：必须出现在对端表中，当Local Action为RELAY或PROXY时，此字段标识消息被路由到的地址，当为REDIRECT时,表示消息应该重定向到的一个或多个服务器。

5. Static or Dynamic: 路由信息是静态配置还是动态发现。

6. Expiration time:与对端表中的含义相同。

另外，路由表必须包含一条默认路由。

Diameter消息应用层的路由

1. 创建和发送Request消息：

1) 产生一个Request消息时，必须遵守下列规则：

· 设置头部的Command code；

· 设置头部的 'R' 位；

· 设置头部的End-to-End 为本地的唯一值；

· Origin-Host 和 Origin-Realm AVPs 必须携带, 用来标识消息的源地址；

· Destination-Host 和 Destination-Realm AVPs 需根据以下规则设置；

a) 不能被Proxy的消息一定不能带Destination-Realm and Destination-Host AVPs；

b) 如果消息是发往某个realm而不是具体的host，则只携带Destination-Realm AVP；

c) 如果消息是发往某个具体的host，则需要同时携带Destination-Realm and Destination-Host AVPs；

· 如果消息有可能被转发，则消息中还必须携带下列AVP之一：an Acct-Application-Id AVP, an Auth-Application-Id AVP or a Vendor-Specific-Application-Id AVP；

2) 当发送一个Request消息时，无论是源主机发送还是Agent转发，都需要执行下列操作：

a) 设置头部的Hop-by-Hop为本地的唯一值；

b) 将该消息放入Pending Request消息队列；

2. 收到Request消息：

1) 当一个Diameter节点收到一个Request消息后，有如下四种可能的处理方式：

a) 如果满足如下条件，则本地处理：

· Destination-Host AVP包含了本地host的标识,或者

· Destination-Host AVP 不存在, Destination-Realm AVP 经过在路由表中查询被配置为本地处理, 或者

· Destination-Host 和 Destination-Realm 都不存在；

b) 如果Destination-Host AVP存在于本地的Peer table中，则执行Request Forwarding：

c) 如果没有本地处理也没有进行Request forwarding，则根据 Destination-Realm AVP 和 Auth-Application-Id 或 Acct-Application-Id 或 Vendor-Specific-Application-Id 查找Realm Routing Table，执行Request Routing；

d) 返回错误DIAMETER_UNABLE_TO_DELIVER ；

注意：这里区分了Request forwarding和Request Routing；本文其它地方提到的“转发”都是泛指消息非本地处理的情况；

2) Request消息在被Relay或者Proxy的时候，Relay Agent和Proxy Agent需要做如下工作：

a) 在转发出去的Request消息中插入Route-Record AVP，里面包含发送该Request消息的主机标识；

b) 保存和该Request消息相关的：Protocol， IP Address， Port， Hop-by-Hop标识；保存这些信息是为了收到与该Reqeuest消息对应的Answer消息后能够将Answer消息正确的转发出去；

3. 创建Answer消息：

当一个Request消息被本地处理后，必须按照如下规则创建并发送Answer消息：

· 从Request消息中拷贝Hop-by-Hop填入Answer消息；

· 将本地主机标识作为Origin-Host AVP；

· Destination-Host 和 Destination-Realm AVPs 不允许出现在Answer消息中；

· 加上 Result-Code AVP 指示成功与否.

· 如果Reqeust消息中包含了Session-Id，那么Answer消息中也应该包含该值；

· 在Request消息中的任何Proxy-Info AVPs 都应原封不动的拷贝到Answer消息中；

· 'P' 位需要和Request消息中保持一致；

· End-to-End 需要和Request消息中保持一致；

4. 收到Answer消息：

当收到一个Answer消息时需要如下操作：

· 检查其Hop-by-Hop，从Pending Request队列中找到与其一致的Reqeust消息，然后将Reqeust消息从Pending Request队列中删除；

· 如果是Agent收到Answer消息，Agent需要将Hop-by-Hop替换为先前保存的Reqeust中的Hop-by-Hop，然后再将Answer消息转发出去；

下图是Diameter节点abc.example.com经由Relay Agent发送一个Request消息给xyz.example.net并收到Answer消息的示意图，该图主要为了说明Hop-by-Hop和End-to-End两个标识的作用：

Diameter基础协议摘要

Diameter是新一代AAA协议，可以承载与TCP或者SCTP协议之上，被广泛应用于IMS，LTE网络中。RFC3588定义了Diameter的基础协议，各种应用可以在此基础上对其进行扩展(主要是定义新的Application ID，Command和AVP)；基础协议中包括一个基本的Accounting功能，如果需要Authentication或者Authorization通常需要进行对基础协议扩展。

1. 基本概念：

· Connection: 是传输层的概念，负责在两端直接传输Diameter消息；

· Session: 是应用层的概念，可以用Session-id 这AVP来标识；下图展示了Connection与Session的区别；

+--------+ +-------+ +--------+

+--------+ +-------+ +--------+

<----------> <---------->

peer connection A peer connection B

<---------------------------------------------------->

User session x

· Destination Host：用于标识一台运行Diameter应用的主机，命名方式类似DNS格式，但并不是域名，只是一个标识符而已，一台运行Diameter应用的主机可以支持一个或者多个Diameter应用；

· Destination Realm：用于标识一组运行Diameter应用的主机，可以将多台Host划归为一个Realm中；

· Peer Table：用于消息路由的数据配置， Peer table中的主机都是能和本地主机之间通信的(也就是说中间无需经过消息转发)，格式如下表：

Host identity

StatusT

Static or Dynamic

Expiration time

abc.example.com

R-Open

statically

xyz.example.net

R-Open

dynamically

· Realm-Based Routing Table : 用于消息路由的数据配置，格式如下表：

Realm Name

Application Identifier

Local Action

Server Identifier

Static or Dynamic

Expiration time

example

16777250

RELAY

abc.example.com

statically

example

16777272

RELAY

xyz.example.net

dynamically

2. Diameter Agents：

· Relay Agents：对消息进行转发，只增加或者删除路由信息，而不会修改任何应用层信息；在CER/CEA进行能力交互时，需要返回自己支持的Application ID为Relay Application Identifier ；使用Relay Agents的好处是简化网络的复杂性，不需要对所有Diameter节点都进行复杂的配置，比如只需配置节点让Diameter消息转发到Relay Agents，然后在Relay Agents上进行比较全面的路由配置即可。

· Proxy Agents：Proxy Agents也负责转发消息，与Relay Agent不同的是，它需要理解应用层的信息，进而维护Transaction的状态；在CER/CEA进行能力交互时，需要返回自己支持的所有Application ID；

· Redirect Agents：收到Diameter消息后不进行转发，而是回复一个应答消息给发送者，应答消息中包含一个或者多个地址，告诉发送者应该将消息发往这些地址；

· Translation Agents：完成Radius和Diameter协议之间的转换；

3. 消息格式：

MAC header

IP header

SCTP | TCP header

Diameter header

Data :::

1) Diameter header:

AVP[] :::

· Version: Diameter的版本号，目前为1；

· Message length：包含头部在内的消息长度，也就是头部+所有AVP的长度之和；

· Flags:

R(equest):如果置位表示这是一个Request消息；

P(roxiable)：如果被置位说明该消息可以被转发，否则必须本地处理；

E(rror)：如果置位，说明产生了一个协议错误，只能出现在Answer消息中；

T:如果被置位，说明该消息有可能是一个被重传的消息；

r:保留位；

· Code:消息命令码，用来标识各种Diameter消息，由IANA负责统一分配；

· Application ID:用来表示不同的Diameter应用，由IANA负责统一分配；

· Hop by Hop ID：用来匹配Request和Answer消息，在一个指定的Connection上的任何时间都必须是唯一的；该值在Diameter消息转发时会被Agent修改；

· End to End ID：用来识别重复消息；该值在本地的一段时间内必须是唯一的，传输过程中一直保持不变；目标主机会根据该值和Original-Host AVP来判读是否是重复消息；

2) AVP header:

AVP code

AVP flags

AVP length

Vendor ID (Optional)

Data :::

· AVP code：用来标识一个AVP，由IANA来统一分配；

· AVP flags：

V, Vendor specific: 如果置位说明 Vendor ID 存在；

M, Mandatory：如果置位说明该AVP是必须的；

P：如果置位说明需要保证该AVP端到端的安全性；

r：reserved

· AVP length：AVP长度；

· Vendor ID：可选的，如果AVP flags中的V被置位，说明该域存在；该值也是由IANA分配的；

4. Diameter和连接相关的三对基本消息：

Diamete通过传输层TCP/SCTP建立连接后，传输的第一个消息就是CER/CEA，通过该消息的交互了解对端都支持哪些应用，看是否有共同的应用；如果对端是Relay Agent，则认为肯定存在共同应用；获知对方支持你哪些应用后，发送消息的时候就不会发送对方不认识的消息，对方对收到的不认识的消息也不会处理。此外双方的IP地址也会在CER/CEA消息中交换。CER/CEA是不能被Proxy，Relay或者是Redirection的，所以说CER/CEA只能是直连节点之间的交换，如果节点A经过Relay Agent发送消息到节点B，那么需要建立两个连接，进行两次CER/CEA的交互。当需要断开连接时，主动方需要发起DPR消息给对端指示断开传输层连接。在连接期间，双方需要互发DWR/DWA (Watching Dog) 消息，用来检测对方是否处于Active状态.

5. 如何看规范中的Diameter命令的ABNF 定义:

具体参见协议的3.2，这里用一个例子大概总结一下：

Example-Request ::= < "Diameter-Header: 9999999, REQ, PXY，123456 >

<Session-Id> //该AVP必须存在一个，且位置固定

{ User-Name } //该AVP必须存在一个

[ Destination-Host ] //该AVP可存在一个或者不存在

1*{ Origin-Host } //该AVP可存在一个或者多个

*[ AVP ] //该AVP可存在零个或者多个

本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请点击举报。