Diameter协议基础：4G信令解析与认证的关键文档

5星 · 超过95%的资源需积分: 24 164 浏览量更新于2024-07-16 收藏 191KB PDF 举报

"rfc3588-diameter.pdf 是一份关于 Diameter 协议的 RFC（Request for Comments）文档，由 P. Calhoun 等人编写，属于 Internet 标准化协议，主要应用于 4G 信令解析，特别在 4A（Authentication、Authorization、Accounting）认证、鉴权和计费场景。该协议是 Radius 协议的增强版，设计用于更高效和安全的网络服务管理。" Diameter 基础协议详细说明： Diameter 协议是为网络接入或 IP 移动性应用设计的一种 Authentication、Authorization 和 Accounting (AAA) 框架。它不仅适用于本地 AAA 服务，还支持漫游情况。RFC 3588 定义了 Diameter 协议的基础，包括消息格式、传输机制、错误报告、计费服务以及安全服务，这些都构成了所有 Diameter 应用的基础组件。 1. **消息格式**：Diameter 协议定义了一套标准化的消息结构，允许通信双方交换请求和响应信息。这些消息包含命令码、应用标识符、事务ID和可选的AVPs（Attribute-Value Pairs），用于携带具体的信息和服务请求。 2. **传输**：Diameter 协议通常使用可靠的传输协议如 TCP 或 SCTP，以确保消息的完整性和顺序，相比 Radius 的 UDP 协议，提供了更高的可靠性。 3. **错误报告**：Diameter 提供了一种详细的错误处理机制，通过返回特定的错误代码，使得服务器能够明确地告知客户端错误原因，有助于故障排查和系统优化。 4. **计费服务**：Diameter 协议支持实时和非实时的计费功能，允许网络运营商追踪和管理用户的使用情况，从而进行计费和资源控制。 5. **安全性**：Diameter 提供了增强的安全服务，如使用 TLS 或 IPsec 对传输数据进行加密，确保通信过程中的数据隐私和完整性。 6. **应用扩展**：Diameter 协议的设计允许通过添加新的 AVPs 和扩展命令来适应不断变化的网络环境和新出现的服务需求，这使得它成为一种灵活且可扩展的框架。 7. **漫游支持**：对于移动网络，Diameter 能够处理用户在不同网络之间的漫游，实现跨域认证和计费，这对于全球化的网络服务至关重要。 RFC 3588 定义的 Diameter 协议是网络服务管理和控制的关键技术，它提升了 Radius 的性能和安全性，为现代网络服务提供了强大而灵活的 AAA 支持。

RFC 3588 Diameter Based Protocol September 2003

Interim accounting

An interim accounting message provides a snapshot of usage during

a user’s session. It is typically implemented in order to provide

for partial accounting of a user’s session in the case of a device

reboot or other network problem prevents the reception of a

session summary message or session record.

Local Realm

A local realm is the administrative domain providing services to a

user. An administrative domain MAY act as a local realm for

certain users, while being a home realm for others.

Multi-session

A multi-session represents a logical linking of several sessions.

Multi-sessions are tracked by using the Acct-Multi-Session-Id. An

example of a multi-session would be a Multi-link PPP bundle. Each

leg of the bundle would be a session while the entire bundle would

be a multi-session.

Network Access Identifier

The Network Access Identifier, or NAI [NAI], is used in the

Diameter protocol to extract a user’s identity and realm. The

identity is used to identify the user during authentication and/or

authorization, while the realm is used for message routing

purposes.

Proxy Agent or Proxy

In addition to forwarding requests and responses, proxies make

policy decisions relating to resource usage and provisioning.

This is typically accomplished by tracking the state of NAS

devices. While proxies typically do not respond to client

Requests prior to receiving a Response from the server, they may

originate Reject messages in cases where policies are violated.

As a result, proxies need to understand the semantics of the

messages passing through them, and may not support all Diameter

applications.

Realm

The string in the NAI that immediately follows the ’@’ character.

NAI realm names are required to be unique, and are piggybacked on

the administration of the DNS namespace. Diameter makes use of

the realm, also loosely referred to as domain, to determine

whether messages can be satisfied locally, or whether they must be

routed or redirected. In RADIUS, realm names are not necessarily

piggybacked on the DNS namespace but may be independent of it.

Calhoun, et al. Standards Track [Page 16]

RFC 3588 Diameter Based Protocol September 2003

Real-time Accounting

Real-time accounting involves the processing of information on

resource usage within a defined time window. Time constraints are

typically imposed in order to limit financial risk.

Relay Agent or Relay

Relays forward requests and responses based on routing-related

AVPs and realm routing table entries. Since relays do not make

policy decisions, they do not examine or alter non-routing AVPs.

As a result, relays never originate messages, do not need to

understand the semantics of messages or non-routing AVPs, and are

capable of handling any Diameter application or message type.

Since relays make decisions based on information in routing AVPs

and realm forwarding tables they do not keep state on NAS resource

usage or sessions in progress.

Redirect Agent

Rather than forwarding requests and responses between clients and

servers, redirect agents refer clients to servers and allow them

to communicate directly. Since redirect agents do not sit in the

forwarding path, they do not alter any AVPs transiting between

client and server. Redirect agents do not originate messages and

are capable of handling any message type, although they may be

configured only to redirect messages of certain types, while

acting as relay or proxy agents for other types. As with proxy

agents, redirect agents do not keep state with respect to sessions

or NAS resources.

Roaming Relationships

Roaming relationships include relationships between companies and

ISPs, relationships among peer ISPs within a roaming consortium,

and relationships between an ISP and a roaming consortium.

Security Association

A security association is an association between two endpoints in

a Diameter session which allows the endpoints to communicate with

integrity and confidentially, even in the presence of relays

and/or proxies.

Session

A session is a related progression of events devoted to a

particular activity. Each application SHOULD provide guidelines

as to when a session begins and ends. All Diameter packets with

the same Session-Identifier are considered to be part of the same

session.

Calhoun, et al. Standards Track [Page 17]

RFC 3588 Diameter Based Protocol September 2003

Session state

A stateful agent is one that maintains session state information,

by keeping track of all authorized active sessions. Each

authorized session is bound to a particular service, and its state

is considered active either until it is notified otherwise, or by

expiration.

Sub-session

A sub-session represents a distinct service (e.g., QoS or data

characteristics) provided to a given session. These services may

happen concurrently (e.g., simultaneous voice and data transfer

during the same session) or serially. These changes in sessions

are tracked with the Accounting-Sub-Session-Id.

Transaction state

The Diameter protocol requires that agents maintain transaction

state, which is used for failover purposes. Transaction state

implies that upon forwarding a request, the 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. A stateless agent is one that only maintains

transaction state.

Translation Agent

A translation agent is a stateful Diameter node that performs

protocol translation between Diameter and another AAA protocol,

such as RADIUS.

Transport Connection

A transport connection is a TCP or SCTP connection existing

directly between two Diameter peers, otherwise known as a Peer-

to-Peer Connection.

Upstream

Upstream is used to identify the direction of a particular

Diameter message from the access device towards the home server.

User

The entity requesting or using some resource, in support of which

a Diameter client has generated a request.

2. Protocol Overview

The base Diameter protocol may be used by itself for accounting

applications, but for use in authentication and authorization it is

always extended for a particular application. Two Diameter

applications are defined by companion documents: NASREQ [NASREQ],

Calhoun, et al. Standards Track [Page 18]

RFC 3588 Diameter Based Protocol September 2003

Mobile IPv4 [DIAMMIP]. These applications are introduced in this

document but specified elsewhere. Additional Diameter applications

MAY be defined in the future (see Section 11.3).

Diameter Clients MUST support the base protocol, which includes

accounting. In addition, they MUST fully support each Diameter

application that is needed to implement the client’s service, e.g.,

NASREQ and/or Mobile IPv4. A Diameter Client that does not support

both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X

Client" where X is the application which it supports, and not a

"Diameter Client".

Diameter Servers MUST support the base protocol, which includes

accounting. In addition, they MUST fully support each Diameter

application that is needed to implement the intended service, e.g.,

NASREQ and/or Mobile IPv4. A Diameter Server that does not support

both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X

Server" where X is the application which it supports, and not a

"Diameter Server".

Diameter Relays and redirect agents are, by definition, protocol

transparent, and MUST transparently support the Diameter base

protocol, which includes accounting, and all Diameter applications.

Diameter proxies MUST support the base protocol, which includes

accounting. In addition, they MUST fully support each Diameter

application that is needed to implement proxied services, e.g.,

NASREQ and/or Mobile IPv4. A Diameter proxy which does not support

also both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X

Proxy" where X is the application which it supports, and not a

"Diameter Proxy".

The base Diameter protocol concerns itself with capabilities

negotiation, how messages are sent and how peers may eventually be

abandoned. The base protocol also defines certain rules that apply

to all exchanges of messages between Diameter nodes.

Communication between Diameter peers begins with one peer sending a

message to another Diameter peer. The set of AVPs included in the

message is determined by a particular Diameter application. One AVP

that is included to reference a user’s session is the Session-Id.

The initial request for authentication and/or authorization of a user

would include the Session-Id. The Session-Id is then used in all

subsequent messages to identify the user’s session (see Section 8 for

more information). The communicating party may accept the request,

or reject it by returning an answer message with the Result-Code AVP

Calhoun, et al. Standards Track [Page 19]

RFC 3588 Diameter Based Protocol September 2003

set to indicate an error occurred. The specific behavior of the

Diameter server or client receiving a request depends on the Diameter

application employed.

Session state (associated with a Session-Id) MUST be freed upon

receipt of the Session-Termination-Request, Session-Termination-

Answer, expiration of authorized service time in the Session-Timeout

AVP, and according to rules established in a particular Diameter

application.

2.1. Transport

Transport profile is defined in [AAATRANS].

The base Diameter protocol is run on port 3868 of both TCP [TCP] and

SCTP [SCTP] transport protocols.

Diameter clients MUST support either TCP or SCTP, while agents and

servers MUST support both. Future versions of this specification MAY

mandate that clients support SCTP.

A Diameter node MAY initiate connections from a source port other

than the one that it declares it accepts incoming connections on, and

MUST be prepared to receive connections on port 3868. A given

Diameter instance of the peer state machine MUST NOT use more than

one transport connection to communicate with a given peer, unless

multiple instances exist on the peer in which case a separate

connection per process is allowed.

When no transport connection exists with a peer, an attempt to

connect SHOULD be periodically made. This behavior is handled via

the Tc timer, whose recommended value is 30 seconds. There are

certain exceptions to this rule, such as when a peer has terminated

the transport connection stating that it does not wish to

communicate.

When connecting to a peer and either zero or more transports are

specified, SCTP SHOULD be tried first, followed by TCP. See Section

5.2 for more information on peer discovery.

Diameter implementations SHOULD be able to interpret ICMP protocol

port unreachable messages as explicit indications that the server is

not reachable, subject to security policy on trusting such messages.

Diameter implementations SHOULD also be able to interpret a reset

from the transport and timed-out connection attempts.

Calhoun, et al. Standards Track [Page 20]

剩余146页未读，继续阅读

weixin_44431046

粉丝: 0
资源: 3

Diameter协议基础：4G信令解析与认证的关键文档

RFC3588_RFC3261中文版

rfc3588.rar_Dimater协议_IETF RFC 3588_RFC 3588_rfc_rfc3588中文版

Diameter协议-rfc3588

diameter.pdf

diameter rfc3588

SIP协议标准RFC3261-RFC2543

083-2008中国联通IT系统BSS系统域在线计费系统业务规范V1.0.pdf

基于IPv6的AAA及其在接入路由器上的实现.pdf

Radius协议.7z

Seagull Diameter协议指南：入门与配置

最新资源