Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 5997 FreeRADIUS
Updates: 2866 August 2010
Category: Informational
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 5997 FreeRADIUS
Updates: 2866 August 2010
Category: Informational
ISSN: 2070-1721
Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol
在远程身份验证拨入用户服务（RADIUS）协议中使用状态服务器数据包
Abstract
摘要
This document describes a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to query the status of a RADIUS server. This extension utilizes the Status-Server (12) Code, which was reserved for experimental use in RFC 2865.
本文档描述了远程身份验证拨入用户服务（RADIUS）协议的已部署扩展，使客户端能够查询RADIUS服务器的状态。此扩展使用状态服务器（12）代码，该代码在RFC2865中保留供实验使用。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5997.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5997.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Applicability ..............................................3
1.2. Terminology ................................................4
1.3. Requirements Language ......................................4
2. Overview ........................................................4
2.1. Why Access-Request is Inappropriate ........................6
2.1.1. Recommendation against Access-Request ...............7
2.2. Why Accounting-Request is Inappropriate ....................7
2.2.1. Recommendation against Accounting-Request ...........7
3. Packet Format ...................................................8
3.1. Single Definition for Status-Server .......................10
4. Implementation Notes ...........................................10
4.1. Client Requirements .......................................11
4.2. Server Requirements .......................................12
4.3. Failover with Status-Server ...............................14
4.4. Proxy Server Handling of Status-Server ....................14
4.5. Limitations of Status-Server ..............................15
4.6. Management Information Base (MIB) Considerations ..........17
4.6.1. Interaction with RADIUS Server MIB Modules .........17
4.6.2. Interaction with RADIUS Client MIB Modules .........17
5. Table of Attributes ............................................18
6. Examples .......................................................19
6.1. Minimal Query to Authentication Port ......................19
6.2. Minimal Query to Accounting Port ..........................20
6.3. Verbose Query and Response ................................21
7. Security Considerations ........................................21
8. References .....................................................23
8.1. Normative References ......................................23
8.2. Informative References ....................................23
Acknowledgments ...................................................24
1. Introduction ....................................................3
1.1. Applicability ..............................................3
1.2. Terminology ................................................4
1.3. Requirements Language ......................................4
2. Overview ........................................................4
2.1. Why Access-Request is Inappropriate ........................6
2.1.1. Recommendation against Access-Request ...............7
2.2. Why Accounting-Request is Inappropriate ....................7
2.2.1. Recommendation against Accounting-Request ...........7
3. Packet Format ...................................................8
3.1. Single Definition for Status-Server .......................10
4. Implementation Notes ...........................................10
4.1. Client Requirements .......................................11
4.2. Server Requirements .......................................12
4.3. Failover with Status-Server ...............................14
4.4. Proxy Server Handling of Status-Server ....................14
4.5. Limitations of Status-Server ..............................15
4.6. Management Information Base (MIB) Considerations ..........17
4.6.1. Interaction with RADIUS Server MIB Modules .........17
4.6.2. Interaction with RADIUS Client MIB Modules .........17
5. Table of Attributes ............................................18
6. Examples .......................................................19
6.1. Minimal Query to Authentication Port ......................19
6.2. Minimal Query to Accounting Port ..........................20
6.3. Verbose Query and Response ................................21
7. Security Considerations ........................................21
8. References .....................................................23
8.1. Normative References ......................................23
8.2. Informative References ....................................23
Acknowledgments ...................................................24
This document specifies a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to query the status of a RADIUS server. While the Status-Server (12) Code was defined as experimental in [RFC2865], Section 3, details of the operation and potential uses of the Code were not provided.
本文档指定了远程身份验证拨入用户服务（RADIUS）协议的已部署扩展，使客户端能够查询RADIUS服务器的状态。虽然[RFC2865]第3节将状态服务器（12）代码定义为实验性代码，但未提供操作细节和代码的潜在用途。
As with the core RADIUS protocol, the Status-Server extension is stateless, and queries do not otherwise affect the normal operation of a server, nor do they result in any side effects, other than perhaps incrementing an internal packet counter. Most of the implementations of this extension have utilized it alongside implementations of RADIUS as defined in [RFC2865], so that this document focuses solely on the use of this extension with UDP transport.
与核心RADIUS协议一样，状态服务器扩展是无状态的，查询不会影响服务器的正常运行，也不会产生任何副作用，除了可能增加内部数据包计数器。此扩展的大多数实现都将其与[RFC2865]中定义的RADIUS实现一起使用，因此本文档仅关注此扩展与UDP传输的使用。
The rest of this document is laid out as follows. Section 2 contains the problem statement, and explanations as to why some possible solutions can have unwanted side effects. Section 3 defines the Status-Server packet format. Section 4 contains client and server requirements, along with some implementation notes. Section 5 contains a RADIUS table of attributes. The remaining text discusses security considerations not covered elsewhere in the document.
本文件的其余部分如下所示。第2节包含问题陈述，以及解释为什么一些可能的解决方案会产生不必要的副作用。第3节定义了状态服务器数据包格式。第4节包含客户端和服务器需求，以及一些实现说明。第5节包含属性的半径表。其余文本讨论了本文件其他部分未涉及的安全注意事项。
This protocol is being recommended for publication as an Informational RFC rather than as a Standards-Track RFC because of problems with deployed implementations. This includes security vulnerabilities. The fixes recommended here are compatible with existing servers that receive Status-Server packets, but impose new security requirements on clients that send Status-Server packets.
由于部署的实现存在问题，建议将此协议作为信息RFC而不是标准跟踪RFC发布。这包括安全漏洞。此处推荐的修复程序与接收状态服务器数据包的现有服务器兼容，但对发送状态服务器数据包的客户端提出了新的安全要求。
Some existing implementations of this protocol do not support the Message-Authenticator attribute ([RFC3579]). This enables an unauthorized client to spoof Status-Server packets, potentially leading to incorrect Access-Accepts. In order to remedy this problem, this specification requires the use of the Message-Authenticator attribute to provide per-packet authentication and integrity protection.
此协议的某些现有实现不支持消息验证器属性（[RFC3579]）。这使未经授权的客户端能够伪造状态服务器数据包，可能导致不正确的访问。为了解决此问题，本规范要求使用消息验证器属性来提供每个数据包的身份验证和完整性保护。
With existing implementations of this protocol, the potential exists for Status-Server requests to be in conflict with Access-Request or Accounting-Request packets using the same Identifier. This specification recommends techniques to avoid this problem.
对于该协议的现有实现，状态服务器请求可能与使用相同标识符的访问请求或记帐请求数据包发生冲突。本规范推荐了避免此问题的技术。
These limitations are discussed in more detail below.
下面将更详细地讨论这些限制。
This document uses the following terms:
本文件使用以下术语：
"Network Access Server (NAS)"
“网络访问服务器（NAS）”
The device providing access to the network. Also known as the Authenticator (in IEEE 802.1X terminology) or RADIUS client.
提供网络访问的设备。也称为验证器（在IEEE 802.1X术语中）或RADIUS客户端。
"RADIUS Proxy"
“半径代理”
In order to provide for the routing of RADIUS authentication and accounting requests, a RADIUS proxy can be employed. To the NAS, the RADIUS proxy appears to act as a RADIUS server, and to the RADIUS server, the proxy appears to act as a RADIUS client.
为了提供RADIUS身份验证和记帐请求的路由，可以使用RADIUS代理。对于NAS，RADIUS代理似乎充当RADIUS服务器；对于RADIUS服务器，代理似乎充当RADIUS客户端。
"silently discard"
“悄悄地丢弃”
This means the implementation discards the packet without further processing. The implementation MAY provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.
这意味着实现将丢弃数据包，而无需进一步处理。该实现可以提供记录错误的能力，包括静默丢弃的数据包的内容，并且应该在统计计数器中记录事件。
In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
在本文件中，使用了几个词来表示规范的要求。本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Status-Server packets are sent by a RADIUS client to a RADIUS server in order to test the status of that server. The destination of a Status-Server packet is set to the IP address and port of the server that is being tested. A single Status-Server packet MUST be included within a UDP datagram. A Message-Authenticator attribute MUST be included so as to provide per-packet authentication and integrity protection.
状态服务器数据包由RADIUS客户端发送到RADIUS服务器，以测试该服务器的状态。状态服务器数据包的目的地设置为正在测试的服务器的IP地址和端口。UDP数据报中必须包含单个状态服务器数据包。必须包括消息验证器属性，以便提供每个数据包的身份验证和完整性保护。
RADIUS proxies or servers MUST NOT forward Status-Server packets. A RADIUS server or proxy implementing this specification SHOULD respond to a Status-Server packet with an Access-Accept (authentication port) or Accounting-Response (accounting port). An Access-Challenge
RADIUS代理或服务器不得转发状态服务器数据包。实现此规范的RADIUS服务器或代理应使用Access Accept（身份验证端口）或Accounting Response（记帐端口）响应状态服务器数据包。访问挑战
response is NOT RECOMMENDED. An Access-Reject response MAY be used. The list of attributes that are permitted in Status-Server packets, and in Access-Accept or Accounting-Response packets responding to Status-Server packets, is provided in Section 5. Section 6 provides several examples.
不建议进行响应。可以使用访问拒绝响应。第5节提供了状态服务器数据包以及响应状态服务器数据包的Access Accept或Accounting Response数据包中允许的属性列表。第6节提供了几个例子。
Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy or server, the client is provided with an indication of the status of that server only, since no RADIUS proxies are on the path between the RADIUS client and server. As servers respond to a Status-Server packet without examining the User-Name attribute, the response to a Status-Server packet cannot be used to infer any information about the reachability of specific realms.
由于状态服务器数据包不得由RADIUS代理或服务器转发，因此客户端仅提供该服务器状态的指示，因为RADIUS客户端和服务器之间的路径上没有RADIUS代理。由于服务器响应状态服务器数据包而不检查用户名属性，因此对状态服务器数据包的响应不能用于推断有关特定领域的可访问性的任何信息。
The "hop-by-hop" functionality of Status-Server packets is useful to RADIUS clients attempting to determine the status of the first element on the path between the client and a server. Since the Status-Server packet is non-forwardable, the lack of a response may only be due to packet loss or the failure of the server at the destination IP address, and not due to faults in downstream links, proxies, or servers. It therefore provides an unambiguous indication of the status of a server.
状态服务器数据包的“逐跳”功能对于RADIUS客户端尝试确定客户端和服务器之间路径上第一个元素的状态非常有用。由于状态服务器分组是不可转发的，因此缺少响应可能只是由于分组丢失或目标IP地址处的服务器故障，而不是由于下游链路、代理或服务器中的故障。因此，它提供了服务器状态的明确指示。
This information may be useful in situations in which the RADIUS client does not receive a response to an Access-Request. A client may have multiple proxies configured, with one proxy marked as primary and another marked as secondary. If the client does not receive a response to a request sent to the primary proxy, it can "failover" to the secondary, and send requests to the secondary proxy instead.
在RADIUS客户端未收到访问请求响应的情况下，此信息可能很有用。一个客户端可以配置多个代理，其中一个代理标记为主代理，另一个标记为辅助代理。如果客户端没有收到对发送到主代理的请求的响应，它可以“故障切换”到辅助代理，并将请求发送到辅助代理。
However, it is possible that the lack of a response to requests sent to the primary proxy was due not to a failure within the primary, but to alternative causes such as a failed link along the path to the destination server or the failure of the destination server itself.
但是，对发送到主代理的请求没有响应可能不是由于主代理内的故障，而是由于其他原因，例如到目标服务器的路径上的链路故障或目标服务器本身的故障。
In such a situation, it may be useful for the client to be able to distinguish between failure causes so that it does not trigger failover inappropriately. For example, if the primary proxy is down, then a quick failover to the secondary proxy would be prudent; whereas, if a downstream failure is the cause, then the value of failover to a secondary proxy will depend on whether packets forwarded by the secondary will utilize independent links, intermediaries, or destination servers.
在这种情况下，客户机能够区分故障原因，这样就不会不适当地触发故障切换，这可能很有用。例如，如果主代理已关闭，则快速故障切换到辅助代理将是明智之举；然而，如果下游故障是原因，则故障转移到辅助代理的价值将取决于辅助代理转发的数据包是否使用独立的链路、中介或目标服务器。
The Status-Server packet is not a "Keep-Alive" as discussed in [RFC2865], Section 2.6. "Keep-Alives" are Access-Request packets sent to determine whether a downstream server is responsive. These packets are typically sent only when a server is suspected to be down, and they are no longer sent as soon as the server is available again.
状态服务器数据包不是[RFC2865]第2.6节中讨论的“保持活动”。“保持有效”是发送的访问请求数据包，用于确定下游服务器是否响应。这些数据包通常仅在怀疑服务器停机时发送，并且一旦服务器再次可用，就不再发送这些数据包。
One possible solution to the problem of querying server status is for a NAS to send specially formed Access-Request packets to a RADIUS server's authentication port. The NAS can then look for a response and use this information to determine if the server is active or unresponsive.
查询服务器状态问题的一个可能解决方案是NAS向RADIUS服务器的身份验证端口发送特殊格式的访问请求数据包。然后，NAS可以查找响应，并使用此信息确定服务器处于活动状态还是无响应状态。
However, the server may see the request as a normal login request for a user and conclude that a real user has logged onto that NAS. The server may then perform actions that are undesirable for a simple status query. The server may alternatively respond with an Access-Challenge, indicating that it believes an extended authentication conversation is necessary.
但是，服务器可能会将该请求视为用户的正常登录请求，并断定真实用户已登录到该NAS。然后，服务器可能会执行简单状态查询不需要的操作。服务器也可以用访问质询来响应，这表示它认为扩展的身份验证对话是必要的。
Another possibility is that the server responds with an Access-Reject, indicating that the user is not authorized to gain access to the network. As above, the server may also perform local-site actions, such as warning an administrator of failed login attempts. The server may also delay the Access-Reject response, in the traditional manner of rate-limiting failed authentication attempts. This delay in response means that the querying administrator is unsure as to whether or not the server is down, slow to respond, or intentionally delaying its response to the query.
另一种可能性是，服务器以访问拒绝响应，这表示用户未被授权访问网络。如上所述，服务器还可以执行本地站点操作，例如警告管理员登录尝试失败。服务器还可以以传统的速率限制失败的身份验证尝试的方式延迟访问拒绝响应。此响应延迟意味着查询管理员不确定服务器是否停机、响应速度慢或故意延迟其对查询的响应。
In addition, using Access-Request queries may mean that the server may have local users configured whose sole reason for existence is to enable these query requests. Unless the server policy is designed carefully, it may be possible for an attacker to use those credentials to gain unauthorized network access.
此外，使用访问请求查询可能意味着服务器可能配置了本地用户，其存在的唯一原因是启用这些查询请求。除非仔细设计服务器策略，否则攻击者可能会使用这些凭据获得未经授权的网络访问。
We note that some NAS implementations currently use Access-Request packets as described above, with a fixed (and non-configurable) user name and password. Implementation issues with that equipment mean that if a RADIUS server does not respond to those queries, it may be marked as unresponsive by the NAS. This marking may happen even if the server is actively responding to other Access-Requests from that same NAS. This behavior is confusing to administrators who then need to determine why an active server has been marked as "unresponsive".
我们注意到，一些NAS实现目前使用如上所述的访问请求数据包，具有固定（且不可配置）用户名和密码。该设备的实施问题意味着，如果RADIUS服务器不响应这些查询，NAS可能会将其标记为无响应。即使服务器正在积极响应来自同一NAS的其他访问请求，也可能发生此标记。这种行为让管理员感到困惑，他们需要确定活动服务器被标记为“无响应”的原因。
For the reasons outlined above, NAS implementors SHOULD NOT generate Access-Request packets solely to see if a server is alive. Similarly, site administrators SHOULD NOT configure test users whose sole reason for existence is to enable such queries via Access-Request packets.
出于上述原因，NAS实施者不应仅为了查看服务器是否处于活动状态而生成访问请求数据包。类似地，站点管理员不应配置测试用户，因为其存在的唯一原因是通过访问请求包启用此类查询。
Note that it still may be useful to configure test users for the purpose of performing end-to-end or in-depth testing of a server policy. While this practice is widespread, we caution administrators to use it with care.
请注意，为了执行服务器策略的端到端或深入测试，配置测试用户可能仍然有用。虽然这种做法很普遍，但我们提醒管理员小心使用。
A similar solution for the problem of querying server status may be for a NAS to send specially formed Accounting-Request packets to a RADIUS server's accounting port. The NAS can then look for a response and use this information to determine if the server is active or unresponsive.
查询服务器状态问题的类似解决方案可能是NAS向RADIUS服务器的记帐端口发送特殊格式的记帐请求数据包。然后，NAS可以查找响应，并使用此信息确定服务器处于活动状态还是无响应状态。
As seen above with Access-Request, the server may then conclude that a real user has logged onto a NAS, and perform local-site actions that are undesirable for a simple status query.
如上所述，对于访问请求，服务器可能会得出结论，认为真实用户已登录到NAS，并执行本地站点操作，这对于简单的状态查询是不可取的。
Another consideration is that some attributes are mandatory to include in an Accounting-Request. This requirement forces the administrator to query an accounting server with fake values for those attributes in a test packet. These fake values increase the work required to perform a simple query, and they may pollute the server's accounting database with incorrect data.
另一个考虑因素是，某些属性必须包含在记帐请求中。这一要求迫使管理员使用测试数据包中那些属性的假值查询记帐服务器。这些伪值增加了执行简单查询所需的工作量，并且可能会用不正确的数据污染服务器的记帐数据库。
For the reasons outlined above, NAS implementors SHOULD NOT generate Accounting-Request packets solely to see if a server is alive. Similarly, site administrators SHOULD NOT configure accounting policies whose sole reason for existence is to enable such queries via Accounting-Request packets.
出于上述原因，NAS实施者不应仅为了查看服务器是否处于活动状态而生成记帐请求数据包。类似地，站点管理员不应配置记帐策略，其存在的唯一原因是通过记帐请求数据包启用此类查询。
Note that it still may be useful to configure test users for the purpose of performing end-to-end or in-depth testing of a server's policy. While this practice is widespread, we caution administrators to use it with care.
请注意，为了执行服务器策略的端到端或深入测试，配置测试用户可能仍然有用。虽然这种做法很普遍，但我们提醒管理员小心使用。
Status-Server packets reuse the RADIUS packet format, with the fields and values for those fields as defined in [RFC2865], Section 3. We do not include all of the text or diagrams of that section here, but instead explain the differences required to implement Status-Server.
状态服务器数据包重用RADIUS数据包格式，这些数据包的字段和值如[RFC2865]第3节所定义。这里我们不包括该部分的所有文本或图表，而是解释实现Status Server所需的差异。
The Authenticator field of Status-Server packets MUST be generated using the same method as that used for the Request Authenticator field of Access-Request packets, as given below.
状态服务器数据包的Authenticator字段必须使用与访问请求数据包的Request Authenticator字段相同的方法生成，如下所示。
The role of the Identifier field is the same for Status-Server as for other packets. However, as Status-Server is taking the role of Access-Request or Accounting-Request packets, there is the potential for Status-Server requests to be in conflict with Access-Request or Accounting-Request packets with the same Identifier. In Section 4.2 below, we describe a method for avoiding these problems. This method MUST be used to avoid conflicts between Status-Server and other packet types.
对于Status Server，标识符字段的角色与其他数据包相同。但是，由于状态服务器扮演访问请求或记帐请求数据包的角色，因此状态服务器请求可能与具有相同标识符的访问请求或记帐请求数据包发生冲突。在下面的第4.2节中，我们描述了避免这些问题的方法。此方法必须用于避免状态服务器和其他数据包类型之间的冲突。
Request Authenticator
请求验证器
In Status-Server packets, the Authenticator value is a 16-octet random number called the Request Authenticator. The value SHOULD be unpredictable and unique over the lifetime of a secret (the password shared between the client and the RADIUS server), since repetition of a request value in conjunction with the same secret would permit an attacker to reply with a previously intercepted response. Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the Request Authenticator field SHOULD exhibit global and temporal uniqueness. See [RFC4086] for suggestions as to how random numbers may be generated.
在状态服务器数据包中，验证器值是一个16个八位组的随机数，称为请求验证器。该值在机密（客户端和RADIUS服务器之间共享的密码）的生命周期内应该是不可预测和唯一的，因为与相同机密一起重复请求值将允许攻击者使用先前截获的响应进行回复。由于预期相同的秘密可用于对不同地理区域中的服务器进行身份验证，因此请求验证器字段应显示全局唯一性和时间唯一性。有关如何生成随机数的建议，请参见[RFC4086]。
The Request Authenticator value in a Status-Server packet SHOULD also be unpredictable, lest an attacker trick a server into responding to a predicted future request, and then use the response to masquerade as that server to a future Status-Server request from a client.
状态服务器数据包中的请求验证器值也应该是不可预测的，以免攻击者诱使服务器响应预测的未来请求，然后使用响应伪装为该服务器响应来自客户端的未来状态服务器请求。
Similarly, the Response Authenticator field of an Access-Accept packet sent in response to Status-Server queries MUST be generated using the same method as used for calculating the Response Authenticator of the Access-Accept sent in response to an Access-Request, with the Status-Server Request Authenticator taking the place of the Access-Request Request Authenticator.
类似地，为响应状态服务器查询而发送的访问接受数据包的响应验证器字段必须使用与用于计算为响应访问请求而发送的访问接受的响应验证器相同的方法生成，状态服务器请求验证器取代访问请求验证器。
The Response Authenticator field of an Accounting-Response packet sent in response to Status-Server queries MUST be generated using the same method as used for calculating the Response Authenticator of the Accounting-Response sent in response to an Accounting-Request, with the Status-Server Request Authenticator taking the place of the Accounting-Request Request Authenticator.
为响应状态服务器查询而发送的记帐响应数据包的响应验证器字段必须使用与计算为响应记帐请求而发送的记帐响应的响应验证器相同的方法生成，状态服务器请求验证器取代记帐请求验证器。
Note that when a server responds to a Status-Server request, it MUST NOT send more than one Response packet.
请注意，当服务器响应状态服务器请求时，它不能发送多个响应数据包。
Response Authenticator
响应验证器
The value of the Authenticator field in Access-Accept or Accounting-Response packets is called the Response Authenticator, and contains a one-way MD5 hash calculated over a stream of octets consisting of: the RADIUS packet, beginning with the Code field, including the Identifier, the Length, the Request Authenticator field from the Status-Server packet, and the response Attributes (if any), followed by the shared secret. That is,
Access Accept或Accounting Response数据包中Authenticator字段的值称为Response Authenticator，它包含一个单向MD5散列，该散列通过八位字节流计算得出，八位字节流包括：RADIUS数据包，从代码字段开始，包括标识符、长度、，Status Server数据包中的Request Authenticator字段和响应属性（如果有），后跟共享机密。就是，
ResponseAuth =
MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
ResponseAuth =
MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
where + denotes concatenation.
其中+表示串联。
In addition to the above requirements, all Status-Server packets MUST include a Message-Authenticator attribute. Failure to do so would mean that the packets could be trivially spoofed.
除上述要求外，所有状态服务器数据包必须包含消息验证器属性。如果不这样做，则意味着数据包可能会被轻微地欺骗。
Status-Server packets MAY include NAS-Identifier, and one of NAS-IP-Address or NAS-IPv6-Address. These attributes are not necessary for the operation of Status-Server, but may be useful information to a server that receives those packets.
状态服务器数据包可能包括NAS标识符和NAS IP地址或NAS-IPv6-Address中的一个。这些属性对于Status Server的操作不是必需的，但对于接收这些数据包的服务器来说可能是有用的信息。
Other attributes SHOULD NOT be included in a Status-Server packet, and MUST be ignored if they are included. User authentication credentials such as User-Name, User-Password, CHAP-Password, EAP-Message MUST NOT appear in a Status-Server packet sent to a RADIUS authentication port. User or NAS accounting attributes such as Acct-Session-Id, Acct-Status-Type, Acct-Input-Octets MUST NOT appear in a Status-Server packet sent to a RADIUS accounting port.
状态服务器数据包中不应包含其他属性，如果包含这些属性，则必须忽略它们。用户身份验证凭据（如用户名、用户密码、CHAP密码、EAP消息）不得出现在发送到RADIUS身份验证端口的状态服务器数据包中。发送到RADIUS记帐端口的状态服务器数据包中不得出现用户或NAS记帐属性，如Acct会话Id、Acct状态类型、Acct输入八位字节。
The Access-Accept MAY contain a Reply-Message or Message-Authenticator attribute. It SHOULD NOT contain other attributes. The Accounting-Response packets sent in response to a Status-Server query SHOULD NOT contain any attributes. As the intent is to
访问接受可能包含回复消息或消息验证器属性。它不应该包含其他属性。为响应状态服务器查询而发送的记帐响应数据包不应包含任何属性。因为目的是
implement a simple query instead of user authentication or accounting, there is little reason to include other attributes in either the query or the corresponding response.
实现一个简单的查询而不是用户身份验证或记帐，几乎没有理由在查询或相应的响应中包含其他属性。
Examples of Status-Server packet flows are given below in Section 6.
下面第6节给出了状态服务器数据包流的示例。
When sent to a RADIUS accounting port, the contents of the Status-Server packets are calculated as described above. That is, even though the packets are being sent to an accounting port, they are not created using the same method as is used for Accounting-Requests. This difference has a number of benefits.
当发送到RADIUS记帐端口时，状态服务器数据包的内容如上所述进行计算。也就是说，即使数据包被发送到记帐端口，它们也不会使用与记帐请求相同的方法创建。这种差异有很多好处。
Having a single definition for Status-Server packets is simpler than having different definitions for different destination ports. In addition, if we were to define Status-Server as being similar to Accounting-Request but containing no attributes, then those packets could be trivially forged.
对状态服务器数据包使用单一定义比对不同的目标端口使用不同的定义更简单。此外，若我们将Status Server定义为类似于记帐请求但不包含属性，那个么这些数据包可能会被伪造。
We therefore define Status-Server consistently, and vary the response packets depending on the port to which the request is sent. When sent to an authentication port, the response to a Status-Server query is an Access-Accept packet. When sent to an accounting port, the response to a Status-Server query is an Accounting-Response packet.
因此，我们一致地定义Status Server，并根据请求发送到的端口改变响应数据包。当发送到身份验证端口时，对状态服务器查询的响应是访问接受数据包。当发送到记帐端口时，对状态服务器查询的响应是记帐响应数据包。
There are a number of considerations to take into account when implementing support for Status-Server. This section describes implementation details and requirements for RADIUS clients and servers that support Status-Server.
在实现对Status Server的支持时，需要考虑许多因素。本节介绍支持Status Server的RADIUS客户端和服务器的实施细节和要求。
The following text applies to the authentication and accounting ports. We use the generic terms below to simplify the discussion:
以下文本适用于身份验证和记帐端口。我们使用以下通用术语简化讨论：
* Request packet
* 请求包
An Access-Request packet sent to an authentication port or an Accounting-Request packet sent to an accounting port.
发送到认证端口的访问请求数据包或发送到记帐端口的记帐请求数据包。
* Response packet
* 响应包
An Access-Accept, Access-Challenge, or Access-Reject packet sent from an authentication port or an Accounting-Response packet sent from an accounting port.
从身份验证端口发送的访问接受、访问质询或访问拒绝数据包，或从记帐端口发送的记帐响应数据包。
We also refer to "client" as the originator of the Status-Server packet, and "server" as the receiver of that packet and the originator of the Response packet.
我们还将“客户机”称为状态服务器数据包的发起人，“服务器”称为该数据包的接收方和响应数据包的发起人。
Using generic terms to describe the Status-Server conversations is simpler than duplicating the text for authentication and accounting packets.
使用通用术语描述状态服务器对话比复制用于身份验证和记帐数据包的文本更简单。
Clients SHOULD permit administrators to globally enable or disable the generation of Status-Server packets. The default SHOULD be that it is disabled. As it is undesirable to send queries to servers that do not support Status-Server, clients SHOULD also have a per-server configuration indicating whether or not to enable Status-Server for a particular destination. The default SHOULD be that it is disabled.
客户端应允许管理员全局启用或禁用状态服务器数据包的生成。默认情况下，应将其禁用。由于不希望向不支持Status Server的服务器发送查询，因此客户端还应该具有每服务器配置，指示是否为特定目标启用Status Server。默认情况下，应将其禁用。
The client SHOULD use a watchdog timer, such as is defined in Section 2.2.1 of [RFC5080], to determine when to send Status-Server packets.
客户机应使用[RFC5080]第2.2.1节中定义的看门狗定时器来确定何时发送状态服务器数据包。
When Status-Server packets are sent from a client, they MUST NOT be retransmitted. Instead, the Identity field MUST be changed every time a packet is transmitted. The old packet should be discarded, and a new Status-Server packet should be generated and sent, with new Identity and Authenticator fields.
从客户端发送状态服务器数据包时，不得重新传输这些数据包。相反，每次传输数据包时必须更改标识字段。应丢弃旧数据包，并应生成和发送新的状态服务器数据包，其中包含新的标识和验证器字段。
Clients MUST include the Message-Authenticator attribute in all Status-Server packets. Failure to do so would mean that the packets could be trivially spoofed, leading to potential denial-of-service (DoS) attacks. Other attributes SHOULD NOT appear in a Status-Server packet, except as outlined below in Section 5. As the intent of the packet is a simple status query, there is little reason for any additional attributes to appear in Status-Server packets.
客户端必须在所有状态服务器数据包中包含Message Authenticator属性。如果不这样做，则意味着数据包可能会受到轻微的欺骗，从而导致潜在的拒绝服务（DoS）攻击。其他属性不应出现在状态服务器数据包中，第5节中概述的情况除外。由于数据包的目的是一个简单的状态查询，因此几乎没有理由在status Server数据包中显示任何附加属性。
The client MAY increment packet counters as a result of sending a Status-Server request or of receiving a Response packet. The client MUST NOT perform any other action that is normally performed when it receives a Response packet, such as permitting a user to have login access to a port.
客户端可以作为发送状态服务器请求或接收响应分组的结果来增加分组计数器。客户端不得执行通常在收到响应数据包时执行的任何其他操作，例如允许用户登录端口。
Clients MAY send Status-Server requests to the RADIUS destination ports from the same source port used to send normal Request packets. Other clients MAY choose to send Status-Server requests from a unique source port that is not used to send Request packets.
客户端可以从用于发送正常请求数据包的同一源端口向RADIUS目标端口发送状态服务器请求。其他客户端可以选择从不用于发送请求数据包的唯一源端口发送状态服务器请求。
The above suggestion for a unique source port for Status-Server packets aids in matching responses to requests. Since the response to a Status-Server packet is an Access-Accept or Accounting-Response
上述为状态服务器数据包提供唯一源端口的建议有助于匹配对请求的响应。因为对状态服务器数据包的响应是访问接受或记帐响应
packet, those responses are indistinguishable from other packets sent in response to a Request packet. Therefore, the best way to distinguish them from other traffic is to have a unique port.
数据包，这些响应与响应请求数据包而发送的其他数据包无法区分。因此，将其与其他流量区分开来的最佳方法是使用唯一的端口。
A client MAY send a Status-Server packet from a source port also used to send Request packets. In that case, the Identifier field MUST be unique across all outstanding Request packets for that source port, independent of the value of the RADIUS Code field for those outstanding requests. Once the client has either received a response to the Status-Server packet or determined that the Status-Server packet has timed out, it may reuse that Identifier in another packet.
客户端可以从也用于发送请求数据包的源端口发送状态服务器数据包。在这种情况下，标识符字段在该源端口的所有未完成请求数据包中必须是唯一的，与这些未完成请求的RADIUS代码字段的值无关。一旦客户端已经接收到对状态服务器分组的响应或者确定状态服务器分组已经超时，它可以在另一个分组中重用该标识符。
Robust implementations SHOULD accept any Response packet as a valid response to a Status-Server packet, subject to the validation requirements defined above for the Response Authenticator. The Code field of the packet matters less than the fact that a valid, signed response has been received.
健壮的实现应该接受任何响应数据包作为对状态服务器数据包的有效响应，并遵守上面为响应验证器定义的验证要求。数据包的代码字段比接收到有效的签名响应更重要。
That is, prior to accepting the response as valid, the client should check that the Response packet Code field is either Access-Accept (2) or Accounting-Response (5). If the Code does not match any of these values, the packet MUST be silently discarded. The client MUST then validate the Response Authenticator via the algorithm given above in Section 3. If the Response Authenticator is not valid, the packet MUST be silently discarded. If the Response Authenticator is valid, then the packet MUST be deemed to be a valid response from the server.
也就是说，在将响应接受为有效之前，客户端应检查响应包代码字段是否为访问接受（2）或记帐响应（5）。如果代码与这些值中的任何一个都不匹配，则必须以静默方式丢弃数据包。然后，客户端必须通过上文第3节中给出的算法验证响应验证器。如果响应验证器无效，则必须以静默方式丢弃数据包。如果响应验证器有效，则必须将数据包视为来自服务器的有效响应。
If the client instead discarded the response because the packet Code did not match what it expected, then it could erroneously discard valid responses from a server, and mark that server as unresponsive. This behavior would affect the stability of a RADIUS network, as responsive servers would erroneously be marked as unresponsive. We therefore recommend that clients should be liberal in what they accept as responses to Status-Server queries.
如果客户机因为数据包代码与预期不匹配而放弃响应，那么它可能会错误地放弃来自服务器的有效响应，并将该服务器标记为无响应。这种行为会影响RADIUS网络的稳定性，因为响应服务器会被错误地标记为无响应。因此，我们建议客户机在接受作为对状态服务器查询的响应时应该自由。
Servers SHOULD permit administrators to globally enable or disable the acceptance of Status-Server packets. The default SHOULD be that acceptance is enabled. Servers SHOULD also permit administrators to enable or disable acceptance of Status-Server packets on a per-client basis. The default SHOULD be that acceptance is enabled.
服务器应允许管理员全局启用或禁用接受状态服务器数据包。默认情况下，应启用接受。服务器还应允许管理员在每个客户端的基础上启用或禁用接受状态服务器数据包。默认情况下，应启用接受。
Status-Server packets originating from clients that are not permitted to send the server Request packets MUST be silently discarded. If a server does not support Status-Server packets, or is configured not to respond to them, then it MUST silently discard the packet.
来自不允许发送服务器请求数据包的客户端的状态服务器数据包必须以静默方式丢弃。如果服务器不支持Status server数据包，或配置为不响应这些数据包，则必须以静默方式丢弃该数据包。
We note that [RFC2865], Section 3, defines a number of RADIUS Codes, but does not make statements about which Codes are valid for port 1812. In contrast, [RFC2866], Section 3, specifies that only RADIUS Accounting packets are to be sent to port 1813. This specification is compatible with [RFC2865], as it uses a known Code for packets to port 1812. This specification is not compatible with [RFC2866], as it adds a new Code (Status-Server) that is valid for port 1812. However, as the category of [RFC2866] is Informational, this conflict is acceptable.
我们注意到[RFC2865]第3节定义了许多RADIUS代码，但没有说明哪些代码对端口1812有效。相反，[RFC2866]第3节规定，只有RADIUS记帐数据包才会发送到端口1813。此规范与[RFC2865]兼容，因为它使用已知代码将数据包发送到端口1812。此规范与[RFC2866]不兼容，因为它添加了对端口1812有效的新代码（状态服务器）。但是，由于[RFC2866]的类别是信息性的，因此这种冲突是可以接受的。
Servers SHOULD silently discard Status-Server packets if they determine that a client is sending too many Status-Server requests in a particular time period. The method used by a server to make this determination is implementation specific and out of scope for this specification.
如果服务器确定某个客户机在特定时间段内发送了太多的状态服务器请求，则服务器应以静默方式丢弃状态服务器数据包。服务器用于进行此确定的方法是特定于实现的，超出了本规范的范围。
If a server supports Status-Server packets, and is configured to respond to them, and receives a packet from a known client, it MUST validate the Message-Authenticator attribute as defined in [RFC3579], Section 3.2. Packets failing that validation MUST be silently discarded.
如果服务器支持状态服务器数据包，并且配置为响应这些数据包，并从已知客户端接收数据包，则必须验证[RFC3579]第3.2节中定义的消息验证器属性。未通过验证的数据包必须以静默方式丢弃。
Servers SHOULD NOT otherwise discard Status-Server packets if they have recently sent the client a Response packet. The query may have originated from an administrator who does not have access to the Response packet stream or one who is interested in obtaining additional information about the server.
如果服务器最近向客户端发送了响应数据包，则不应丢弃状态服务器数据包。查询可能来自无权访问响应数据包流的管理员或有兴趣获取有关服务器的附加信息的管理员。
The server MAY prioritize the handling of Status-Server packets over the handling of other requests, subject to the rate limiting described above.
根据上述速率限制，服务器可以将状态服务器分组的处理优先于其他请求的处理。
The server MAY decide not to respond to a Status-Server, depending on local-site policy. For example, a server that is running but is unable to perform its normal activities MAY silently discard Status-Server packets. This situation can happen, for example, when a server requires access to a database for normal operation, but the connection to that database is down. Or, it may happen when the accepted load on the server is lower than the offered load.
服务器可能决定不响应状态服务器，具体取决于本地站点策略。例如，正在运行但无法执行其正常活动的服务器可能会自动放弃状态服务器数据包。例如，当服务器需要访问数据库才能正常运行，但与该数据库的连接已断开时，可能会发生这种情况。或者，当服务器上接受的负载低于提供的负载时，可能会发生这种情况。
Some server implementations require that Access-Request packets be accepted only on "authentication" ports (e.g., 1812/udp), and that Accounting-Request packets be accepted only on "accounting" ports (e.g., 1813/udp). Those implementations SHOULD reply to Status-Server packets sent to an "authentication" port with an Access-Accept packet and SHOULD reply to Status-Server packets sent to an "accounting" port with an Accounting-Response packet.
一些服务器实现要求仅在“身份验证”端口（例如1812/udp）上接受访问请求数据包，并且仅在“记帐”端口（例如1813/udp）上接受记帐请求数据包。这些实现应该使用访问接受数据包回复发送到“身份验证”端口的状态服务器数据包，并且应该使用记帐响应数据包回复发送到“记帐”端口的状态服务器数据包。
Some server implementations accept both Access-Request and Accounting-Request packets on the same port, and they do not distinguish between "authentication only" ports and "accounting only" ports. Those implementations SHOULD reply to Status-Server packets with an Access-Accept packet.
一些服务器实现在同一端口上接受访问请求和记帐请求数据包，并且它们不区分“仅验证”端口和“仅记帐”端口。这些实现应该使用Access-Accept数据包回复Status-Server数据包。
The server MAY increment packet counters as a result of receiving a Status-Server packet or sending a Response packet. The server SHOULD NOT perform any other action that is normally performed when it receives a Request packet, other than sending a Response packet.
服务器可以作为接收状态服务器分组或发送响应分组的结果来增加分组计数器。除了发送响应数据包外，服务器不应执行通常在接收请求数据包时执行的任何其他操作。
A client may wish to "failover" from one proxy to another in the event that it does not receive a response to an Access-Request or Accounting-Request. In order to determine whether the lack of response is due to a problem with the proxy or a downstream server, the client can send periodic Status-Server packets to a proxy after the lack of a response.
如果客户端没有收到对访问请求或记帐请求的响应，则可能希望从一个代理“故障切换”到另一个代理。为了确定缺少响应是由于代理服务器还是下游服务器的问题造成的，客户端可以在缺少响应后向代理服务器发送定期状态服务器数据包。
These packets will help the client determine if the failure was due to an issue on the path between the client and proxy or the proxy itself, or whether the issue is occurring downstream.
这些数据包将帮助客户端确定故障是由于客户端和代理之间的路径上的问题还是代理本身的问题，或者问题是否发生在下游。
If no response is received to Status-Server packets, the RADIUS client can initiate failover to another proxy. By continuing to send Status-Server packets to the original proxy, the RADIUS client can determine when it becomes responsive again.
如果没有收到对状态服务器数据包的响应，RADIUS客户端可以启动到另一个代理的故障切换。通过继续向原始代理发送状态服务器数据包，RADIUS客户端可以确定何时再次响应。
Once the server has been deemed responsive, normal RADIUS requests may be sent to it again. This determination should be made separately for each server with which the client has a relationship. The same algorithm SHOULD be used for both authentication and accounting ports. The client MUST treat each destination (IP, port) combination as a unique server for the purposes of this determination.
一旦服务器被视为响应，正常RADIUS请求可能会再次发送给它。对于客户端与之有关系的每台服务器，应分别进行此确定。身份验证和记帐端口应使用相同的算法。为了进行此确定，客户端必须将每个目标（IP、端口）组合视为唯一的服务器。
Clients SHOULD use a retransmission mechanism similar to that given in Section 2.2.1 of [RFC5080]. If a reliable transport is used for RADIUS, then the watchdog timer algorithm specified in [RFC3539] MUST be used.
客户端应使用类似于[RFC5080]第2.2.1节中给出的重传机制。如果RADIUS使用可靠传输，则必须使用[RFC3539]中指定的看门狗定时器算法。
Many RADIUS servers can act as proxy servers, and can forward requests to another RADIUS server. Such servers MUST NOT proxy Status-Server packets. The purpose of Status-Server as specified here is to permit the client to query the responsiveness of a server
许多RADIUS服务器可以充当代理服务器，并可以将请求转发到另一个RADIUS服务器。此类服务器不得代理状态服务器数据包。此处指定的Status Server的目的是允许客户端查询服务器的响应性
with which it has a direct relationship. Proxying Status-Server queries would negate any usefulness that may be gained by implementing support for them.
与之有直接关系。代理状态服务器查询将否定通过实现对它们的支持而获得的任何有用性。
Proxy servers MAY be configured to respond to Status-Server queries from clients, and they MAY act as clients sending Status-Server queries to other servers. However, those activities MUST be independent of one another.
代理服务器可以配置为响应来自客户端的状态服务器查询，它们可以充当向其他服务器发送状态服务器查询的客户端。然而，这些活动必须相互独立。
RADIUS servers are commonly used in an environment where Network Access Identifiers (NAIs) are used as routing identifiers [RFC4282]. In this practice, the User-Name attribute is decorated with realm-routing information, commonly in the format of "user@realm". Since a particular RADIUS server may act as a proxy for more than one realm, we need to explain how the behavior defined above in Section 4.3 affects realm routing.
RADIUS服务器通常用于网络访问标识符（NAI）用作路由标识符的环境[RFC4282]。在这种实践中，用户名属性用领域路由信息修饰，通常采用“user@realm". 由于特定的RADIUS服务器可能充当多个领域的代理，因此我们需要解释上文第4.3节中定义的行为如何影响领域路由。
The schematic below demonstrates this scenario.
下面的示意图演示了这种情况。
/-> RADIUS Proxy P -----> RADIUS Server for Realm A
/ \ /
NAS X
\ / \
\-> RADIUS Proxy S -----> RADIUS Server for Realm B
/-> RADIUS Proxy P -----> RADIUS Server for Realm A
/ \ /
NAS X
\ / \
\-> RADIUS Proxy S -----> RADIUS Server for Realm B
That is, the NAS has relationships with two RADIUS Proxies, P and S. Each RADIUS proxy has relationships with RADIUS servers for both Realm A and Realm B.
也就是说，NAS与两个RADIUS代理（P和S）有关系。每个RADIUS代理都与域A和域B的RADIUS服务器有关系。
In this scenario, the RADIUS proxies can determine if one or both of the RADIUS servers are dead or unreachable. The NAS can determine if one or both of the RADIUS proxies are dead or unreachable. There is an additional case to consider, however.
在这种情况下，RADIUS代理可以确定一个或两个RADIUS服务器是否已关闭或无法访问。NAS可以确定一个或两个RADIUS代理是否失效或无法访问。然而，还有一个需要考虑的案例。
If RADIUS Proxy P cannot reach the RADIUS server for Realm A, but RADIUS Proxy S can reach that RADIUS server, then the NAS cannot discover this information using the Status-Server queries as outlined above. It would therefore be useful for the NAS to know that Realm A is reachable from RADIUS Proxy S, as it can then route all requests for Realm A to that RADIUS proxy. Without this knowledge, the client may route requests to RADIUS Proxy P, where they may be discarded or rejected.
如果RADIUS代理P无法到达域A的RADIUS服务器，但RADIUS代理S可以到达该RADIUS服务器，则NAS无法使用上述状态服务器查询来发现此信息。因此，让NAS知道域A可以从RADIUS代理S访问是非常有用的，因为它可以将域A的所有请求路由到该RADIUS代理。如果不知道这一点，客户端可能会将请求路由到RADIUS代理P，在那里它们可能被丢弃或拒绝。
To complicate matters, the behavior of RADIUS Proxies P and S in this situation is not well defined. Some implementations simply fail to respond to the request, and other implementations respond with an
更复杂的是，在这种情况下，半径代理P和S的行为没有很好的定义。一些实现根本无法响应请求，而其他实现则以
Access-Reject. If the implementation fails to respond, then the NAS cannot distinguish between the RADIUS proxy being down and the next server along the proxy chain being unreachable.
访问拒绝。如果实现没有响应，NAS将无法区分RADIUS代理已关闭和代理链上的下一台服务器无法访问。
In the worst case, failures in routing for Realm A may affect users of Realm B. For example, if RADIUS Proxy P can reach Realm B but not Realm A, and RADIUS Proxy S can reach Realm A but not Realm B, then active paths exist to handle all RADIUS requests. However, depending on the NAS and RADIUS proxy implementation choices, the NAS may not be able to determine to which server requests may be sent in order to maintain network stability.
在最坏的情况下，域A的路由失败可能会影响域B的用户。例如，如果RADIUS代理P可以到达域B但不能到达域A，并且RADIUS代理S可以到达域A但不能到达域B，则存在活动路径来处理所有RADIUS请求。但是，根据NAS和RADIUS代理实施选项的不同，NAS可能无法确定可以向哪些服务器发送请求以保持网络稳定性。
Unfortunately, this problem cannot be solved by using Status-Server requests. A robust solution would involve either a RADIUS routing table for the NAI realms or a RADIUS "destination unreachable" response to authentication requests. Either solution would not fit into the traditional RADIUS model, and both are therefore outside of the scope of this specification.
不幸的是，使用状态服务器请求无法解决此问题。一个健壮的解决方案将涉及NAI领域的RADIUS路由表或对身份验证请求的RADIUS“目的地不可到达”响应。这两种解决方案都不适合传统的RADIUS模型，因此都超出了本规范的范围。
The problem is discussed here in order to define how best to use Status-Server in this situation, rather than to define a new solution.
这里讨论这个问题是为了定义在这种情况下如何最好地使用Status Server，而不是定义一个新的解决方案。
When a server has responded recently to a request from a client, that client MUST mark the server as "responsive". In the above case, a RADIUS proxy may be responding to requests destined for Realm A, but not responding to requests destined for Realm B. The client therefore considers the server to be responsive, as it is receiving responses from the server.
当服务器最近响应了来自客户端的请求时，该客户端必须将服务器标记为“响应”。在上述情况下，RADIUS代理可能会响应以领域a为目的地的请求，但不会响应以领域B为目的地的请求。因此，客户端认为服务器是有响应的，因为它正在接收来自服务器的响应。
The client will then continue to send requests to the RADIUS proxy for destination Realm B, even though the RADIUS proxy cannot route the requests to that destination. This failure is a known limitation of RADIUS, and can be partially addressed through the use of failover in the RADIUS proxies.
然后，客户端将继续向目标域B的RADIUS代理发送请求，即使RADIUS代理无法将请求路由到该目标。此故障是已知的RADIUS限制，可以通过在RADIUS代理中使用故障转移部分解决。
A more realistic situation than the one outlined above is one in which each RADIUS proxy also has multiple choices of RADIUS servers for a realm, as outlined below.
与上述情况相比，更现实的情况是，每个RADIUS代理还可以为一个领域选择多个RADIUS服务器，如下所述。
/-> RADIUS Proxy P -----> RADIUS Server P
/ \ /
NAS X
\ / \
\-> RADIUS Proxy S -----> RADIUS Server S
/-> RADIUS Proxy P -----> RADIUS Server P
/ \ /
NAS X
\ / \
\-> RADIUS Proxy S -----> RADIUS Server S
In this situation, if all participants implement Status-Server as defined herein, any one link may be broken, and all requests from the NAS will still reach a RADIUS server. If two links are broken at different places (i.e., not both links from the NAS), then all requests from the NAS will still reach a RADIUS server. In many situations where three or more links are broken, requests from the NAS may still reach a RADIUS server.
在这种情况下，如果所有参与者都实现本文定义的状态服务器，则任何一条链路都可能断开，来自NAS的所有请求仍将到达RADIUS服务器。如果两条链路在不同的位置断开（即不是来自NAS的两条链路），则来自NAS的所有请求仍将到达RADIUS服务器。在许多情况下，三条或更多链路断开，来自NAS的请求仍可能到达RADIUS服务器。
It is RECOMMENDED, therefore, that implementations desiring the most benefit from Status-Server also implement server failover. The combination of these two practices will maximize network reliability and stability.
因此，建议希望从Status Server获得最大好处的实现也实现服务器故障切换。这两种做法的结合将最大限度地提高网络的可靠性和稳定性。
Since Status-Server packets are sent to the defined RADIUS ports, they can affect the [RFC4669] and [RFC4671] RADIUS server MIB modules. [RFC4669] defines a counter named radiusAuthServTotalUnknownTypes that counts "The number of RADIUS packets of unknown type that were received". [RFC4671] defines a similar counter named radiusAccServTotalUnknownTypes. Implementations not supporting Status-Server or implementations that are configured not to respond to Status-Server packets MUST use these counters to track received Status-Server packets.
由于状态服务器数据包被发送到定义的RADIUS端口，它们可能会影响[RFC4669]和[RFC4671]RADIUS服务器MIB模块。[RFC4669]定义一个名为radiusAuthServTotalUnknownTypes的计数器，该计数器统计“接收到的未知类型的RADIUS数据包数”。[RFC4671]定义了一个名为radiusAccServTotalUnknownTypes的类似计数器。不支持状态服务器的实现或配置为不响应状态服务器数据包的实现必须使用这些计数器跟踪收到的状态服务器数据包。
If, however, Status-Server is supported and the server is configured to respond as described above, then the counters defined in [RFC4669] and [RFC4671] MUST NOT be used to track Status-Server requests or responses to those requests. That is, when a server fully implements Status-Server, the counters defined in [RFC4669] and [RFC4671] MUST be unaffected by the transmission or reception of packets relating to Status-Server.
但是，如果支持Status Server，并且服务器配置为如上所述响应，则不得使用[RFC4669]和[RFC4671]中定义的计数器跟踪Status Server请求或对这些请求的响应。也就是说，当服务器完全实现Status server时，[RFC4669]和[RFC4671]中定义的计数器必须不受与Status server相关的数据包的传输或接收的影响。
If a server supports Status-Server and the [RFC4669] or [RFC4671] MIB modules, then it SHOULD also support vendor-specific MIB extensions dedicated solely to tracking Status-Server requests and responses. Any definition of the server MIB modules for Status-Server is outside of the scope of this document.
如果服务器支持Status server和[RFC4669]或[RFC4671]MIB模块，则还应支持专门用于跟踪Status server请求和响应的特定于供应商的MIB扩展。Status server的服务器MIB模块的任何定义都超出了本文档的范围。
Clients implementing Status-Server MUST NOT increment [RFC4668] or [RFC4670] counters upon reception of Response packets to Status-Server queries. That is, when a server fully implements Status-
在接收到状态服务器查询的响应数据包时，实现状态服务器的客户端不得增加[RFC4668]或[RFC4670]计数器。也就是说，当服务器完全实现状态时-
Server, the counters defined in [RFC4668] and [RFC4670] MUST be unaffected by the transmission or reception of packets relating to Status-Server.
[RFC4668]和[RFC4670]中定义的计数器必须不受与状态服务器相关的数据包的发送或接收的影响。
If an implementation supports Status-Server and the [RFC4668] or [RFC4670] MIB modules, then it SHOULD also support vendor-specific MIB extensions dedicated solely to tracking Status-Server requests and responses. Any definition of the client MIB modules for Status-Server is outside of the scope of this document.
如果实现支持Status Server和[RFC4668]或[RFC4670]MIB模块，则还应支持专门用于跟踪Status Server请求和响应的特定于供应商的MIB扩展。Status Server的客户端MIB模块的任何定义都超出了本文档的范围。
The following table provides a guide to which attributes may be found in Status-Server packets, and in what quantity. Attributes other than the ones listed below SHOULD NOT be found in a Status-Server packet.
下表提供了在Status Server数据包中可以找到哪些属性以及数量的指南。在Status Server数据包中不应找到下列属性以外的其他属性。
Status- Access- Accounting-Server Accept Response # Attribute
状态-访问-记帐服务器接受响应#属性
0 0 0 1 User-Name 0 0 0 2 User-Password 0 0 0 3 CHAP-Password 0-1 0 0 4 NAS-IP-Address (Note 1) 0 0+ 0 18 Reply-Message 0+ 0+ 0+ 26 Vendor-Specific 0-1 0 0 32 NAS-Identifier (Note 1) 0 0 0 79 EAP-Message 1 0-1 0-1 80 Message-Authenticator 0-1 0 0 95 NAS-IPv6-Address (Note 1) 0 0 0 103-121 Digest-*
0 0 0 1用户名0 0 0 2用户密码0 0 3 CHAP密码0-1 0 0 4 NAS IP地址（注1）0 0+0 18回复消息0+0+0+26特定于供应商的0-1 0 0 32 NAS标识符（注1）0 0 0 79 EAP消息1 0-1 0-1 80消息验证器0-1 0 95 NAS-IPv6-Address（注1）0 0 0 103-121摘要-*
Note 1: A Status-Server packet SHOULD contain one of (NAS-IP-Address or NAS-IPv6-Address), or NAS-Identifier, or both NAS-Identifier and one of (NAS-IP-Address or NAS-IPv6-Address).
注1：状态服务器数据包应包含（NAS IP地址或NAS-IPv6-Address）或NAS标识符中的一个，或同时包含NAS标识符和（NAS IP地址或NAS-IPv6-Address）中的一个。
The following table defines the meaning of the above table entries.
下表定义了上述表格条目的含义。
0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet. 1 Exactly one instance of this attribute MUST be present in packet.
0此属性不能出现在数据包中。数据包中可能存在0+零个或多个此属性的实例。0-1数据包中可能存在该属性的零个或一个实例。1数据包中必须正好存在此属性的一个实例。
A few examples are presented to illustrate the flow of packets to both the authentication and accounting ports. These examples are not intended to be exhaustive; many others are possible. Hexadecimal dumps of the example packets are given in network byte order, using the shared secret "xyzzy5461".
给出了几个示例来说明数据包到身份验证端口和记帐端口的流程。这些示例并非详尽无遗；其他许多都是可能的。示例数据包的十六进制转储以网络字节顺序给出，使用共享密钥“xyzzy5461”。
The NAS sends a Status-Server UDP packet with minimal content to a RADIUS server on port 1812.
NAS向端口1812上的RADIUS服务器发送内容最少的状态服务器UDP数据包。
The Request Authenticator is a 16-octet random number generated by the NAS. Message-Authenticator is included in order to authenticate that the request came from a known client.
请求验证器是NAS生成的16个八位字节的随机数。包含消息验证器是为了验证请求是否来自已知客户端。
0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02 18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43 82 20 97 c8 4f a3
0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02 18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43 82 20 97 c8 4f a3
1 Code = Status-Server (12) 1 ID = 218 2 Length = 38 16 Request Authenticator
1代码=状态服务器（12）1 ID=218 2长度=38 16请求验证器
Attributes:
18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3
Attributes:
18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3
The Response Authenticator is a 16-octet MD5 checksum of the Code (2), ID (218), Length (20), the Request Authenticator from above, and the shared secret.
响应验证器是由代码（2）、ID（218）、长度（20）、来自上面的请求验证器和共享秘密组成的16个八位MD5校验和。
02 da 00 14 ef 0d 55 2a 4b f2 d6 93 ec 2b 6f e8 b5 41 1d 66
02 da 00 14 ef 0d 55 2a 4b f2 d6 93 ec 2b 6f e8 b5 41 1d 66
1 Code = Access-Accept (2) 1 ID = 218 2 Length = 20 16 Request Authenticator
1代码=访问接受（2）1 ID=218 2长度=20 16请求验证器
Attributes: None.
属性：无。
The NAS sends a Status-Server UDP packet with minimal content to a RADIUS server on port 1813.
NAS向端口1813上的RADIUS服务器发送内容最少的状态服务器UDP数据包。
The Request Authenticator is a 16-octet random number generated by the NAS. Message-Authenticator is included in order to authenticate that the request came from a known client.
请求验证器是NAS生成的16个八位字节的随机数。包含消息验证器是为了验证请求是否来自已知客户端。
0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7 ad 38 82 60 50 12 e8 d6 ea bd a9 10 87 5c d9 1f da de 26 36 78 58
0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7 ad 38 82 60 50 12 e8 d6 ea bd a9 10 87 5c d9 1f da de 26 36 78 58
1 Code = Status-Server (12) 1 ID = 179 2 Length = 38 16 Request Authenticator
1代码=状态服务器（12）1 ID=179 2长度=38 16请求验证器
Attributes:
18 Message-Authenticator (80) = e8d6eabda910875cd91fdade26367858
Attributes:
18 Message-Authenticator (80) = e8d6eabda910875cd91fdade26367858
The Response Authenticator is a 16-octet MD5 checksum of the Code (5), ID (179), Length (20), the Request Authenticator from above, and the shared secret.
响应验证器是由代码（5）、ID（179）、长度（20）、来自上面的请求验证器和共享秘密组成的16个八位MD5校验和。
02 b3 00 14 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a 48 60 66 9c
02 b3 00 14 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a 48 60 66 9c
1 Code = Accounting-Response (5) 1 ID = 179 2 Length = 20 16 Request Authenticator
1代码=记帐响应（5）1 ID=179 2长度=20 16请求验证器
Attributes: None.
属性：无。
The NAS at 192.0.2.16 sends a Status-Server UDP packet to the RADIUS server on port 1812.
位于192.0.2.16的NAS向端口1812上的RADIUS服务器发送状态服务器UDP数据包。
The Request Authenticator is a 16-octet random number generated by the NAS.
请求验证器是NAS生成的16个八位字节的随机数。
0c 47 00 2c bf 58 de 56 ae 40 8a d3 b7 0c 85 13 f9 b0 3f be 04 06 c0 00 02 10 50 12 85 2d 6f ec 61 e7 ed 74 b8 e3 2d ac 2f 2a 5f b2
0c 47 00 2c bf 58 de 56 ae 40 8a d3 b7 0c 85 13 f9 b0 3f be 04 06 c0 00 02 10 50 12 85 2d 6f ec 61 e7 ed 74 b8 e3 2d ac 2f 2a 5f b2
1 Code = Status-Server (12) 1 ID = 71 2 Length = 44 16 Request Authenticator
1代码=状态服务器（12）1 ID=71 2长度=44 16请求验证器
Attributes:
6 NAS-IP-Address (4) = 192.0.2.16
18 Message-Authenticator (80) = 852d6fec61e7ed74b8e32dac2f2a5fb2
Attributes:
6 NAS-IP-Address (4) = 192.0.2.16
18 Message-Authenticator (80) = 852d6fec61e7ed74b8e32dac2f2a5fb2
The Response Authenticator is a 16-octet MD5 checksum of the Code (2), ID (71), Length (52), the Request Authenticator from above, the attributes in this reply, and the shared secret.
响应验证器是由代码（2）、ID（71）、长度（52）、来自上面的请求验证器、此回复中的属性和共享机密组成的16个八位MD5校验和。
The Reply-Message is "RADIUS Server up 2 days, 18:40"
回复信息为“RADIUS服务器启动2天，18:40”
02 47 00 34 46 f4 3e 62 fd 03 54 42 4c bb eb fd 6d 21 4e 06 12 20 52 41 44 49 55 53 20 53 65 72 76 65 72 20 75 70 20 32 20 64 61 79 73 2c 20 31 38 3a 34 30
02 47 00 34 46 f4 3e 62 fd 03 54 42 4c bb eb fd 6d 21 4e 06 12 20 52 41 44 55 53 20 53 65 72 76 72 20 75 70 20 32 20 64 61 79 2c 20 31 38 3a 34 30
1 Code = Access-Accept (2) 1 ID = 71 2 Length = 52 16 Request Authenticator
1代码=访问接受（2）1 ID=71 2长度=52 16请求验证器
Attributes: 32 Reply-Message (18)
属性：32回复消息（18）
This document defines the Status-Server packet as being similar in treatment to the Access-Request packet, and is therefore subject to the same security considerations as described in [RFC2865], Section 8. Status-Server packets also use the Message-Authenticator attribute, and are therefore subject to the same security considerations as [RFC3579], Section 4.
本文件将状态服务器数据包定义为在处理上与访问请求数据包类似，因此需要遵守[RFC2865]第8节所述的相同安全注意事项。状态服务器数据包也使用消息验证器属性，因此需要遵守与[RFC3579]第4节相同的安全注意事项。
We reiterate that Status-Server packets MUST contain a Message-Authenticator attribute. Early implementations supporting Status-Server did not enforce this requirement, and were vulnerable to the following attacks:
我们重申，状态服务器数据包必须包含消息验证器属性。早期支持Status Server的实施未强制执行此要求，易受以下攻击：
* Servers not checking the Message-Authenticator attribute could respond to Status-Server packets from an attacker, potentially enabling a reflected DoS attack onto a real client.
* 未检查Message Authenticator属性的服务器可能会响应来自攻击者的状态服务器数据包，从而可能对真实客户端发起反射式DoS攻击。
* Servers not checking the Message-Authenticator attribute could be subject to a race condition, where an attacker could see an Access-Request packet from a valid client and synthesize a Status-Server packet containing the same Request Authenticator. If the attacker won the race against the valid client, the server could respond with an Access-Accept and potentially authorize unwanted service.
* 未检查Message Authenticator属性的服务器可能会受到竞争条件的影响，在这种情况下，攻击者可以看到来自有效客户端的访问请求数据包，并合成包含相同请求Authenticator的状态服务器数据包。如果攻击者在与有效客户端的竞争中获胜，服务器可能会响应Access Accept并授权不需要的服务。
The last attack is similar to a related attack when Access-Request packets contain a CHAP-Password but no Message-Authenticator. We re-iterate the suggestion of [RFC5080], Section 2.2.2, which proposes that all clients send a Message-Authenticator in every Access-Request packet, and that all servers have a configuration setting to require (or not) that a Message-Authenticator attribute be used in every Access-Request packet.
最后一次攻击类似于访问请求数据包包含CHAP密码但没有消息验证器时的相关攻击。我们再次重申[RFC5080]第2.2.2节的建议，该建议建议所有客户端在每个访问请求数据包中发送消息验证器，并且所有服务器都有一个配置设置，要求（或不要求）在每个访问请求数据包中使用消息验证器属性。
Failure to include a Message-Authenticator attribute in a Status-Server packet means that any RADIUS client or server may be vulnerable to the attacks outlined above. For this reason, implementations of this specification that fail to require use of the Message-Authenticator attribute are NOT RECOMMENDED.
在状态服务器数据包中未包含消息验证器属性意味着任何RADIUS客户端或服务器都可能容易受到上述攻击。因此，不建议使用不需要使用Message Authenticator属性的本规范实现。
Where this document differs from [RFC2865] is that it defines a new request/response method in RADIUS: the Status-Server request. As this use is based on previously described and implemented standards, we know of no additional security considerations that arise from the use of Status-Server as defined herein.
本文档与[RFC2865]的不同之处在于，它在RADIUS中定义了一种新的请求/响应方法：状态服务器请求。由于此使用基于先前描述和实现的标准，因此我们不知道因使用本文定义的Status Server而产生的其他安全注意事项。
Attacks on cryptographic hashes are well known [RFC4270] and getting better with time. RADIUS uses the MD5 hash [RFC1321] for packet authentication and attribute obfuscation. There are ongoing efforts in the IETF to analyze and address these issues for the RADIUS protocol.
对加密散列的攻击是众所周知的[RFC4270]，并且随着时间的推移会越来越好。RADIUS使用MD5哈希[RFC1321]进行数据包身份验证和属性混淆。IETF正在努力分析和解决RADIUS协议的这些问题。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[RFC3539]Aboba，B.和J.Wood，“认证、授权和会计（AAA）传输概要”，RFC 3539，2003年6月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月。
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007.
[RFC5080]Nelson，D.和A.DeKok，“通用远程身份验证拨入用户服务（RADIUS）实施问题和建议修复”，RFC 50802007年12月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866]Rigney，C.，“半径会计”，RFC 28662000年6月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月。
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[RFC4270]Hoffman，P.和B.Schneier，“对互联网协议中加密哈希的攻击”，RFC 42702005年11月。
[RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC 4668, August 2006.
[RFC4668]Nelson，D.，“IPv6的RADIUS身份验证客户端MIB”，RFC 4668，2006年8月。
[RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC 4669, August 2006.
[RFC4669]Nelson，D.，“IPv6的RADIUS认证服务器MIB”，RFC 4669，2006年8月。
[RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670, August 2006.
[RFC4670]Nelson，D.，“IPv6的RADIUS计费客户端MIB”，RFC 46702006年8月。
[RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671, August 2006.
[RFC4671]Nelson，D.，“IPv6的RADIUS计费服务器MIB”，RFC 46712006年8月。
Acknowledgments
致谢
Parts of the text in Section 3 defining the Request and Response Authenticators were taken, with minor edits, from [RFC2865], Section 3.
第3节中定义请求和响应验证器的部分文本来自[RFC2865]第3节，并进行了少量编辑。
The author would like to thank Mike McCauley of Open Systems Consultants for making a Radiator server available for interoperability testing.
作者要感谢开放系统顾问公司的Mike McCauley为互操作性测试提供了散热器服务器。
Ignacio Goyret provided valuable feedback on the history and security of the Status-Server packet.
Ignacio Goyret提供了有关Status Server数据包的历史和安全性的宝贵反馈。
Author's Address
作者地址
Alan DeKok The FreeRADIUS Server Project http://freeradius.org
Alan DeKok FreeRADIUS服务器项目http://freeradius.org
EMail: aland@freeradius.org
EMail: aland@freeradius.org