Network Working Group D. Nelson
Request for Comments: 5080 Elbrys Networks, Inc
Updates: 2865, 2866, 2869, 3579 A. DeKok
Category: Standards Track FreeRADIUS
December 2007
Network Working Group D. Nelson
Request for Comments: 5080 Elbrys Networks, Inc
Updates: 2865, 2866, 2869, 3579 A. DeKok
Category: Standards Track FreeRADIUS
December 2007
Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes
常见远程身份验证拨入用户服务（RADIUS）实施问题和建议的修复
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document describes common issues seen in Remote Authentication Dial In User Service (RADIUS) implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified.
本文档描述了远程身份验证拨入用户服务（RADIUS）实现中常见的问题，并提出了一些修复建议。在适用的情况下，澄清先前半径规范中的歧义和错误。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. Requirements Language ......................................3
2. Issues ..........................................................3
2.1. Session Definition .........................................3
2.1.1. State Attribute .....................................3
2.1.2. Request-ID Supplementation ..........................6
2.2. Overload Conditions ........................................7
2.2.1. Retransmission Behavior .............................7
2.2.2. Duplicate Detection and Orderly Delivery ...........10
2.2.3. Server Response to Overload ........................11
2.3. Accounting Issues .........................................12
2.3.1. Attributes Allowed in an Interim Update ............12
2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ..........12
2.3.3. Request Authenticator ..............................13
2.3.4. Interim-Accounting-Interval ........................13
2.3.5. Counter Values in the RADIUS Management
Information Base (MIB) .............................14
2.4. Multiple Filter-ID Attributes .............................15
2.5. Mandatory and Optional Attributes .........................16
2.6. Interpretation of Access-Reject ...........................18
2.6.1. Improper Use of Access-Reject ......................18
2.6.2. Service Request Denial .............................19
2.7. Addressing ................................................20
2.7.1. Link-Local Addresses ...............................20
2.7.2. Multiple Addresses .................................20
2.8. Idle-Timeout ..............................................21
2.9. Unknown Identity ..........................................21
2.10. Responses After Retransmissions ..........................22
2.11. Framed-IPv6-Prefix .......................................23
3. Security Considerations ........................................24
4. References .....................................................25
4.1. Normative References ......................................25
4.2. Informative References ....................................25
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. Requirements Language ......................................3
2. Issues ..........................................................3
2.1. Session Definition .........................................3
2.1.1. State Attribute .....................................3
2.1.2. Request-ID Supplementation ..........................6
2.2. Overload Conditions ........................................7
2.2.1. Retransmission Behavior .............................7
2.2.2. Duplicate Detection and Orderly Delivery ...........10
2.2.3. Server Response to Overload ........................11
2.3. Accounting Issues .........................................12
2.3.1. Attributes Allowed in an Interim Update ............12
2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ..........12
2.3.3. Request Authenticator ..............................13
2.3.4. Interim-Accounting-Interval ........................13
2.3.5. Counter Values in the RADIUS Management
Information Base (MIB) .............................14
2.4. Multiple Filter-ID Attributes .............................15
2.5. Mandatory and Optional Attributes .........................16
2.6. Interpretation of Access-Reject ...........................18
2.6.1. Improper Use of Access-Reject ......................18
2.6.2. Service Request Denial .............................19
2.7. Addressing ................................................20
2.7.1. Link-Local Addresses ...............................20
2.7.2. Multiple Addresses .................................20
2.8. Idle-Timeout ..............................................21
2.9. Unknown Identity ..........................................21
2.10. Responses After Retransmissions ..........................22
2.11. Framed-IPv6-Prefix .......................................23
3. Security Considerations ........................................24
4. References .....................................................25
4.1. Normative References ......................................25
4.2. Informative References ....................................25
The last few years have seen an increase in the deployment of RADIUS clients and servers. This document describes common issues seen in RADIUS implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified.
过去几年中，RADIUS客户端和服务器的部署有所增加。本文档描述了RADIUS实现中常见的问题，并提出了一些修复建议。在适用的情况下，澄清先前半径规范中的歧义和错误。
This document uses the following terms:
本文件使用以下术语：
Network Access Server (NAS) The device providing access to the network. Also known as the Authenticator in IEEE 802.1X or Extensible Authentication Protocol (EAP) terminology, or RADIUS client.
网络访问服务器（NAS）提供网络访问的设备。在IEEE 802.1X或可扩展身份验证协议（EAP）术语中也称为身份验证程序，或RADIUS客户端。
service The NAS provides a service to the user, such as network access via 802.11 or Point to Point Protocol (PPP).
服务NAS向用户提供服务，例如通过802.11或点对点协议（PPP）进行网络访问。
session Each service provided by the NAS to a peer constitutes a session, with the beginning of the session defined as the point where service is first provided, and the end of the session is defined as the point where service is ended. A peer may have multiple sessions in parallel or series if the NAS supports that, with each session generating a separate start and stop accounting record.
会话NAS向对等方提供的每个服务都构成一个会话，会话的开始定义为首次提供服务的点，会话的结束定义为服务的结束点。如果NAS支持，对等机可以并行或串联多个会话，每个会话生成单独的开始和停止记帐记录。
silently discard This means the implementation discards the packet without further processing. The implementation SHOULD 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]中所述进行解释。
Regarding the State attribute, [RFC2865] Section 5.24 states:
关于状态属性，[RFC2865]第5.24节规定：
This Attribute is available to be sent by the server to the client in an Access-Challenge and MUST be sent unmodified from the client to the server in the new Access-Request reply to that challenge, if any.
此属性可由服务器在访问质询中发送到客户端，并且必须在对该质询的新访问请求答复（如果有）中未经修改地从客户端发送到服务器。
This Attribute is available to be sent by the server to the client in an Access-Accept that also includes a Termination-Action Attribute with the value of RADIUS-Request. If the NAS performs the Termination-Action by sending a new Access-Request upon termination of the current session, it MUST include the State attribute unchanged in that Access-Request.
此属性可由服务器在Access Accept中发送给客户端，该Access Accept还包括一个值为RADIUS Request的Termination Action属性。如果NAS通过在当前会话终止时发送新的访问请求来执行终止操作，则必须在该访问请求中包含State属性unchanged。
Some RADIUS client implementations do not properly use the State attribute in order to distinguish a restarted EAP authentication process from the continuation of an ongoing process (by the same user on the same NAS and port). Where an EAP-Message attribute is included in an Access-Challenge or Access-Accept attribute, RADIUS servers SHOULD also include a State attribute. See Section 2.1.2 on Request ID supplementation for additional benefits to using the State attribute in this fashion.
某些RADIUS客户端实现没有正确使用State属性来区分重新启动的EAP身份验证过程与正在进行的过程（由同一NAS和端口上的同一用户）的继续。当访问质询或访问接受属性中包含EAP消息属性时，RADIUS服务器还应包含状态属性。有关以这种方式使用状态属性的其他好处，请参见第2.1.2节“请求ID补充”。
As defined in [RFC2865] Table 5.44, Access-Request packets may contain a State attribute. The table does not qualify this statement, while the text in Section 5.24 (quoted above) adds other requirements not specified in that table.
如[RFC2865]表5.44中所定义，访问请求数据包可能包含状态属性。该表不限定本声明，而第5.24节（上文引用）中的文本增加了该表中未规定的其他要求。
We extend the requirements of [RFC2865] to say that Access-Requests that are part of an ongoing Access-Request / Access-Challenge authentication process SHOULD contain a State attribute. It is the responsibility of the server, to send a State attribute in an Access-Challenge packet, if that server needs a State attribute in a subsequent Access-Request to tie multiple Access-Requests together into one authentication session. As defined in [RFC2865] Section 5.24, the State MUST be sent unmodified from the client to the server in the new Access-Request reply to that challenge, if any.
我们扩展了[RFC2865]的要求，即作为正在进行的访问请求/访问质询身份验证过程一部分的访问请求应包含状态属性。如果服务器需要后续访问请求中的状态属性将多个访问请求绑定到一个身份验证会话中，则服务器负责在访问质询数据包中发送状态属性。如[RFC2865]第5.24节中所定义，在对该质询的新访问请求回复中（如有），必须将状态未经修改地从客户端发送到服务器。
While most server implementations require the presence of a State attribute in an Access-Challenge packet, some challenge-response systems can distinguish the initial request from the response to the challenge without using a State attribute to track an authentication session. The Access-Challenge and subsequent Access-Request packets for those systems do not need to contain a State attribute.
虽然大多数服务器实现要求访问质询数据包中存在状态属性，但一些质询响应系统可以区分初始请求和质询响应，而无需使用状态属性来跟踪身份验证会话。这些系统的访问质询和后续访问请求数据包不需要包含状态属性。
Other authentication mechanisms need to tie a sequence of Access-Request / Access-Challenge packets together into one ongoing authentication session. Servers implementing those authentication mechanisms SHOULD include a State attribute in Access-Challenge packets.
其他身份验证机制需要将一系列访问请求/访问质询数据包绑定到一个正在进行的身份验证会话中。实现这些身份验证机制的服务器应该在访问质询数据包中包含状态属性。
In general, if the authentication process involves one or more Access-Request / Access-Challenge sequences, the State attribute SHOULD be sent by the server in the Access-Challenge packets. Using the State attribute to create a multi-packet session is the simplest
通常，如果身份验证过程涉及一个或多个访问请求/访问质询序列，则状态属性应由服务器在访问质询数据包中发送。使用State属性创建多数据包会话是最简单的
method available in RADIUS today. While other methods of creating multi-packet sessions are possible (e.g., [RFC3579] Section 2.6.1), those methods are NOT RECOMMENDED.
方法现在在RADIUS中可用。虽然可以使用其他方法创建多数据包会话（如[RFC3579]第2.6.1节），但不建议使用这些方法。
The only permissible values for a State attribute are values provided in an Access-Accept, Access-Challenge, CoA-Request or Disconnect-Request packet. A RADIUS client MUST use only those values for the State attribute that it has previously received from a server. An Access-Request sent as a result of a new or restarted authentication run MUST NOT include the State attribute, even if a State attribute has previously been received in an Access-Challenge for the same user and port.
状态属性的唯一允许值是访问接受、访问质询、CoA请求或断开连接请求数据包中提供的值。RADIUS客户端必须仅对其以前从服务器接收的状态属性使用这些值。由于新的或重新启动的身份验证运行而发送的访问请求不得包含State属性，即使先前已在同一用户和端口的访问质询中收到State属性。
Access-Request packets that contain a Service-Type attribute with the value Authorize Only (17) MUST contain a State attribute. Access-Request packets that contain a Service-Type attribute with value Call Check (10) SHOULD NOT contain a State attribute. Any other Access-Request packet that performs authorization checks MUST contain a State attribute. This last requirement often means that an Access-Accept needs to contain a State attribute, which can then be used in a later Access-Request that performs authorization checks.
包含值为Authorize Only（17）的服务类型属性的访问请求数据包必须包含状态属性。包含值为Call Check（10）的服务类型属性的访问请求数据包不应包含状态属性。执行授权检查的任何其他访问请求数据包必须包含状态属性。最后一个要求通常意味着访问接受需要包含一个状态属性，然后可以在以后执行授权检查的访问请求中使用该属性。
The standard use case for Call Check is pre-screening authentication based solely on the end-point identifier information, such as phone number or Media Access Control (MAC) address in Calling-Station-ID and optionally Called-Station-ID. In this use case, the NAS has no way to obtain a State attribute suitable for inclusion in an Access-Request. Other, non-standard, uses of Call Check may require or permit the use of a State attribute, but are beyond the scope of this document.
呼叫检查的标准用例是仅基于端点标识符信息的预筛选身份验证，如呼叫站ID和可选呼叫站ID中的电话号码或媒体访问控制（MAC）地址。在此用例中，NAS无法获得适合包含在访问请求中的状态属性。调用检查的其他非标准用法可能需要或允许使用状态属性，但超出了本文档的范围。
In an Access-Request with a Service-Type Attribute with value Call Check, it is NOT RECOMMENDED for the User-Name and User-Password attributes to contain the same values (e.g., a MAC address). Implementing MAC address checking without using a Service-Type of Call Check is NOT RECOMMENDED. This practice gives an attacker both the clear-text and cipher-text of the User-Password field, which permits many attacks on the security of the RADIUS protocol. For example, if the Request Authenticator does not satisfy the [RFC2865] requirements on global and temporal uniqueness, the practice described above may lead to the compromise of the User-Password attribute in other Access-Requests for unrelated users. Access to the cipher-text enables offline dictionary attacks, potentially exposing the shared secret and compromising the entire RADIUS protocol.
在具有“值调用检查”的“服务类型”属性的访问请求中，不建议用户名和用户密码属性包含相同的值（例如MAC地址）。不建议在不使用服务类型的呼叫检查的情况下实施MAC地址检查。这种做法为攻击者提供用户密码字段的明文和密文，从而允许对RADIUS协议的安全性进行多次攻击。例如，如果请求验证器不满足关于全局和时间唯一性的[RFC2865]要求，则上述实践可能导致对无关用户的其他访问请求中的用户密码属性的妥协。对密码文本的访问使脱机字典攻击成为可能，这可能会暴露共享机密并破坏整个RADIUS协议。
Any Access-Request packet that performs authorization checks, including Call Check, SHOULD contain a Message-Authenticator attribute. Any response to an Access-Request performing an authorization check MUST NOT contain confidential information about any user (such as Tunnel-Password), unless that Access-Request contains a State attribute. The use of State here permits the authorization check to be tied to an earlier user authentication. In that case, the server MAY respond to the NAS with confidential information about that user. The server MUST NOT respond to that authorization check with confidential information about any other user.
执行授权检查（包括呼叫检查）的任何访问请求数据包都应包含消息验证器属性。对执行授权检查的访问请求的任何响应不得包含任何用户的机密信息（如隧道密码），除非该访问请求包含状态属性。此处使用State允许将授权检查绑定到早期的用户身份验证。在这种情况下，服务器可能会向NAS发送有关该用户的机密信息。服务器不得以任何其他用户的机密信息响应该授权检查。
For an Access-Request packet performing an authorization check that does not contain a State attribute, the server MUST respond with an Access-Reject.
对于执行不包含状态属性的授权检查的访问请求数据包，服务器必须以访问拒绝响应。
[RFC3579] Section 2.6.1 states:
[RFC3579]第2.6.1节规定：
In EAP, each session has its own unique Identifier space. RADIUS server implementations MUST be able to distinguish between EAP packets with the same Identifier existing within distinct sessions, originating on the same NAS. For this purpose, sessions can be distinguished based on NAS and session identification attributes. NAS identification attributes include NAS-Identifier, NAS-IPv6-Address and NAS-IPv4-Address. Session identification attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port-Id, Called-Station-Id, Calling-Station-Id and Originating-Line-Info.
在EAP中，每个会话都有自己的唯一标识符空间。RADIUS服务器实施必须能够区分不同会话中存在相同标识符、源自相同NAS的EAP数据包。为此，可以根据NAS和会话标识属性来区分会话。NAS标识属性包括NAS标识符、NAS-IPv6-Address和NAS-IPv4-Address。会话标识属性包括用户名、NAS端口、NAS端口类型、NAS端口Id、被叫站Id、主叫站Id和始发线路信息。
There are issues with the suggested algorithm. Since proxies may modify Access-Request attributes such as NAS-IP-Address, depending on any attribute under control of the NAS to distinguish request identifiers can result in deployment problems.
建议的算法存在问题。由于代理可以修改诸如NAS IP地址之类的访问请求属性，所以根据NAS控制下的任何属性来区分请求标识符可能会导致部署问题。
The FreeRADIUS implementation does not track EAP identifiers by NAS-IP-Address or other non-EAP attributes sent by the NAS. Instead, it uses the EAP identifier, source Internet Protocol (IP) address, and the State attribute as a "key" to uniquely identify each EAP session. Since the State attribute is under the control of the RADIUS server, the uniqueness of each session is controlled by the server, not the NAS. The algorithm used in FreeRADIUS is as follows:
FreeRADIUS实施不会通过NAS IP地址或NAS发送的其他非EAP属性跟踪EAP标识符。相反，它使用EAP标识符、源Internet协议（IP）地址和状态属性作为“密钥”来唯一标识每个EAP会话。由于State属性由RADIUS服务器控制，因此每个会话的唯一性由服务器控制，而不是由NAS控制。FreeRADIUS中使用的算法如下所示：
if (EAP start, or EAP identity) {
allocate unique State Attribute
insert session into "active session" table with
key=(EAP identifier, State, source IP)
} else {
look up active session in table, with above key
}
if (EAP start, or EAP identity) {
allocate unique State Attribute
insert session into "active session" table with
key=(EAP identifier, State, source IP)
} else {
look up active session in table, with above key
}
This algorithm appears to work well in a variety of situations, including situations where home servers receive messages via intermediate RADIUS proxies.
该算法似乎在各种情况下都能很好地工作，包括家庭服务器通过中间RADIUS代理接收消息的情况。
Implementations that do not use this algorithm are often restricted to having an EAP Identifier space per NAS, or perhaps one that is global to the implementation. These restrictions are unnecessary when the above algorithm is used, which gives each session a unique EAP Identifier space. The above algorithm SHOULD be used to track EAP sessions in preference to any other method.
不使用此算法的实现通常被限制为每个NAS具有EAP标识符空间，或者可能是实现的全局空间。当使用上述算法时，这些限制是不必要的，这为每个会话提供了一个唯一的EAP标识符空间。上述算法应优先用于跟踪EAP会话，而不是任何其他方法。
[RFC2865] Section 2.4 describes the retransmission requirements for RADIUS clients:
[RFC2865]第2.4节描述了RADIUS客户端的重传要求：
At one extreme, RADIUS does not require a "responsive" detection of lost data. The user is willing to wait several seconds for the authentication to complete. The generally aggressive Transmission Control Protocol (TCP) retransmission (based on average round trip time) is not required, nor is the acknowledgment overhead of TCP.
在一个极端情况下，RADIUS不需要对丢失的数据进行“响应式”检测。用户愿意等待几秒钟以完成身份验证。一般主动传输控制协议（TCP）重传（基于平均往返时间）是不需要的，TCP的确认开销也是不需要的。
At the other extreme, the user is not willing to wait several minutes for authentication. Therefore the reliable delivery of TCP data two minutes later is not useful. The faster use of an alternate server allows the user to gain access before giving up.
在另一个极端，用户不愿意等待几分钟进行身份验证。因此，两分钟后可靠地传递TCP数据是没有用的。更快地使用备用服务器允许用户在放弃之前获得访问权限。
Some existing RADIUS clients implement excessively aggressive retransmission behavior, utilizing default retransmission timeouts of one second or less without support for congestive backoff. When deployed at a large scale, these implementations are susceptible to congestive collapse. For example, as the result of a power failure, a network with 3,000 NAS devices with a fixed retransmission timer of one second will continuously generate 3,000 RADIUS Access-Requests per second. This is sufficient to overwhelm most RADIUS servers.
一些现有的RADIUS客户端实现了过度激进的重传行为，利用了一秒或更短的默认重传超时，而不支持拥塞退避。当大规模部署时，这些实现容易出现拥塞崩溃。例如，由于电源故障，具有3000个NAS设备且固定的重发计时器为1秒的网络每秒将连续生成3000个RADIUS访问请求。这足以压倒大多数RADIUS服务器。
Suggested solutions include:
建议的解决办法包括：
[a] Jitter. To avoid synchronization, a RADIUS client SHOULD incorporate induced jitter within its retransmission algorithm, as specified below.
[a] 抖动。为避免同步，RADIUS客户端应在其重传算法中加入诱导抖动，如下所述。
[b] Congestive backoff. While it is not necessary for RADIUS client implementations to implement complex retransmission algorithms, implementations SHOULD support congestive backoff.
[b] 充血性退避。虽然RADIUS客户端实现不需要实现复杂的重传算法，但实现应该支持拥塞退避。
RADIUS retransmission timers are based on the model used in Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. Variables used here are also borrowed from this specification. RADIUS is a request/response-based protocol. The message exchange terminates when the requester successfully receives the answer, or the message exchange is considered to have failed according to the RECOMMENDED retransmission mechanism described below. Other retransmission mechanisms are possible, as long as they satisfy the requirements on jitter and congestive backoff.
RADIUS重传计时器基于IPv6动态主机配置协议（DHCPv6）[RFC3315]中使用的模型。此处使用的变量也借用了本规范。RADIUS是一种基于请求/响应的协议。当请求者成功接收到应答时，消息交换终止，或者根据下面描述的推荐重传机制，消息交换被认为失败。其他重传机制是可能的，只要它们满足抖动和拥塞退避的要求。
The following algorithms apply to any client that originates RADIUS packets, including but not limited to Access-Request, Accounting-Request, Disconnect-Request, and CoA-Request [RFC3576].
以下算法适用于发起RADIUS数据包的任何客户端，包括但不限于访问请求、记帐请求、断开连接请求和CoA请求[RFC3576]。
The retransmission behavior is controlled and described by the following variables:
重传行为由以下变量控制和描述：
RT Retransmission timeout
RT重传超时
IRT Initial retransmission time (default 2 seconds)
IRT初始重传时间（默认为2秒）
MRC Maximum retransmission count (default 5 attempts)
MRC最大重传次数（默认5次尝试）
MRT Maximum retransmission time (default 16 seconds)
MRT最大重传时间（默认16秒）
MRD Maximum retransmission duration (default 30 seconds)
MRD最大重传持续时间（默认为30秒）
RAND Randomization factor
兰德随机化因子
With each message transmission or retransmission, the sender sets RT according to the rules given below. If RT expires before the message exchange terminates, the sender re-computes RT and retransmits the message.
在每次消息传输或重传时，发送方根据下面给出的规则设置RT。如果RT在消息交换终止之前过期，发送方将重新计算RT并重新传输消息。
Each of the computations of a new RT include a randomization factor (RAND), which is a random number chosen with a uniform distribution between -0.1 and +0.1. The randomization factor is included to minimize the synchronization of messages.
新RT的每次计算都包括一个随机化因子（RAND），它是一个均匀分布在-0.1和+0.1之间的随机数。包括随机化因子以最小化消息的同步。
The algorithm for choosing a random number does not need to be cryptographically sound. The algorithm SHOULD produce a different sequence of random numbers from each invocation.
选择一个随机数的算法不需要在密码上可靠。算法应该从每次调用中产生不同的随机数序列。
RT for the first message transmission is based on IRT:
第一次消息传输的RT基于IRT：
RT = IRT + RAND*IRT
RT = IRT + RAND*IRT
RT for each subsequent message retransmission is based on the previous value of RT:
每次后续消息重传的RT基于先前的RT值：
RT = 2*RTprev + RAND*RTprev
RT = 2*RTprev + RAND*RTprev
MRT specifies an upper bound on the value of RT (disregarding the randomization added by the use of RAND). If MRT has a value of 0, there is no upper limit on the value of RT. Otherwise:
MRT指定RT值的上限（忽略使用RAND增加的随机化）。如果MRT的值为0，则RT的值没有上限。否则：
if (RT > MRT)
RT = MRT + RAND*MRT
if (RT > MRT)
RT = MRT + RAND*MRT
MRD specifies an upper bound on the length of time a sender may retransmit a message. The message exchange fails once MRD seconds have elapsed since the client first transmitted the message. MRD MUST be set, and SHOULD have a value between 5 and 30 seconds. These values mirror the values for a server's duplicate detection cache, as described in the next section.
MRD指定发送方可以重新传输消息的时间长度上限。自客户端首次传输消息以来，一旦MRD秒过去，消息交换就会失败。必须设置MRD，其值应在5到30秒之间。这些值镜像服务器的重复检测缓存的值，如下一节所述。
MRC specifies an upper bound on the number of times a sender may retransmit a message. If MRC is zero, the message exchange fails once MRD seconds have elapsed since the client first transmitted the message. If MRC is non-zero, the message exchange fails when either the sender has transmitted the message MRC times, or when MRD seconds have elapsed since the client first transmitted the message.
MRC指定发送方可以重新传输消息的次数上限。如果MRC为零，则在客户机首次传输消息后的MRD秒过后，消息交换将失败。如果MRC为非零，则当发送方已发送消息MRC次，或自客户端首次发送消息以来已过MRD秒时，消息交换将失败。
For Accounting-Request packets, the default values for MRC, MRD, and MRT SHOULD be zero. These settings will enable a RADIUS client to continue sending accounting requests to a RADIUS server until the request is acknowledged. If any of MRC, MRD, or MRT are non-zero, then the accounting information could potentially be discarded without being recorded.
对于记帐请求数据包，MRC、MRD和MRT的默认值应为零。这些设置将使RADIUS客户端能够继续向RADIUS服务器发送记帐请求，直到请求得到确认。如果MRC、MRD或MRT中的任何一项为非零，则会计信息可能会在不记录的情况下被丢弃。
When packets are retransmitted by a client, the server may receive duplicate requests. The limitations of the transport protocol used by RADIUS, the User Datagram Protocol (UDP), means that the Access-Request packets may be received, and potentially processed, in an order different from the order in which the packets were sent. However, the discussion of the Identifier field in Section 3 of [RFC2865] says:
当客户端重新传输数据包时，服务器可能会收到重复的请求。RADIUS使用的传输协议的限制，即用户数据报协议（UDP），意味着访问请求数据包可能会以不同于数据包发送顺序的顺序接收和处理。然而，[RFC2865]第3节中对标识符字段的讨论指出：
The RADIUS server can detect a duplicate request if it has the same client source IP address and source UDP port and Identifier within a short span of time.
如果RADIUS服务器在短时间内具有相同的客户端源IP地址、源UDP端口和标识符，则RADIUS服务器可以检测到重复请求。
Also, Section 7 of [RFC4669] defines a radiusAuthServDupAccessRequests object as:
此外，[RFC4669]的第7节将radiusAuthServDupAccessRequests对象定义为：
The number of duplicate Access-Request packets received.
接收到的重复访问请求数据包数。
This text has a number of implications. First, without duplicate detection, a RADIUS server may process an authentication request twice, leading to an erroneous conclusion that a user has logged in twice. That behavior is undesirable, so duplicate detection is desirable. Second, the server may track not only the duplicate request, but also the replies to those requests. This behavior permits the server to send duplicate replies in response to duplicate requests, increasing network stability.
这一案文有若干含义。首先，在没有重复检测的情况下，RADIUS服务器可能会处理两次身份验证请求，从而得出用户已登录两次的错误结论。这种行为是不可取的，因此需要重复检测。其次，服务器不仅可以跟踪重复请求，还可以跟踪对这些请求的响应。此行为允许服务器发送重复的回复以响应重复的请求，从而提高网络稳定性。
Since Access-Request packets may also be sent by the client in response to an Access-Challenge from the server, those packets form a logically ordered stream, and, therefore have additional ordering requirements over Access-Request packets for different sessions. Implementing duplicate detection results in new packets being processed only once, ensuring order.
由于接入请求分组也可由客户端响应于来自服务器的接入质询而发送，因此这些分组形成逻辑上有序的流，并且因此对于不同会话的接入请求分组具有额外的排序要求。实现重复检测会导致新数据包只被处理一次，从而确保顺序。
RADIUS servers MUST therefore implement duplicate detection for Access-Request packets, as described in Section 3 of [RFC2865]. Implementations MUST also cache the Responses (Access-Accept, Access-Challenge, or Access-Reject) that they send in response to Access-Request packets. If a server receives a valid duplicate Access-Request for which it has already sent a Response, it MUST resend its original Response without reprocessing the request. The server MUST silently discard any duplicate Access-Requests for which a Response has not yet been sent.
因此，RADIUS服务器必须对访问请求数据包实施重复检测，如[RFC2865]第3节所述。实现还必须缓存它们为响应访问请求数据包而发送的响应（访问接受、访问质询或访问拒绝）。如果服务器接收到有效的重复访问请求，并且已经发送了响应，则必须重新发送其原始响应，而无需重新处理该请求。服务器必须以静默方式放弃尚未发送响应的任何重复访问请求。
Each cache entry SHOULD be purged after a period of time. This time SHOULD be no less than 5 seconds, and no more than 30 seconds. After about 30 seconds, most RADIUS clients and end users will have given up on the authentication request. Therefore, there is little value in having a larger cache timeout.
一段时间后，应清除每个缓存项。该时间不得少于5秒，也不得超过30秒。大约30秒后，大多数RADIUS客户端和最终用户将放弃身份验证请求。因此，拥有更大的缓存超时没有什么价值。
Cache entries MUST also be purged if the server receives a valid Access-Request packet that matches a cached Access-Request packet in source address, source port, RADIUS Identifier, and receiving socket, but where the Request Authenticator field is different from the one in the cached packet. If the request contains a Message-Authenticator attribute, the request MUST be processed as described in [RFC3580] Section 3.2. Packets with invalid Message-Authenticators MUST NOT affect the cache in any way.
如果服务器接收到与源地址、源端口、RADIUS标识符和接收套接字中的缓存访问请求数据包匹配的有效访问请求数据包，但请求验证器字段与缓存数据包中的字段不同，则还必须清除缓存项。如果请求包含消息验证器属性，则必须按照[RFC3580]第3.2节所述处理该请求。具有无效消息验证器的数据包不得以任何方式影响缓存。
However, Access-Request packets not containing a Message-Authenticator attribute always affect the cache, even though they may be trivially forged. To avoid this issue, server implementations may be configured to require the presence of a Message-Authenticator attribute in Access-Request packets. Requests not containing a Message-Authenticator attribute MAY then be silently discarded.
但是，不包含消息验证器属性的访问请求数据包始终会影响缓存，即使它们可能是轻微伪造的。为了避免此问题，可以将服务器实现配置为要求访问请求数据包中存在消息验证器属性。然后，不包含消息验证器属性的请求可能会被静默地丢弃。
Client implementations SHOULD include a Message-Authenticator attribute in every Access-Request to further help mitigate this issue.
客户端实现应在每个访问请求中包含消息验证器属性，以进一步帮助缓解此问题。
When sending requests, RADIUS clients MUST NOT reuse Identifiers for a source IP address and source UDP port until either a valid response has been received, or the request has timed out. Clients SHOULD allocate Identifiers via a least-recently-used (LRU) method for a particular source IP address and source UDP port.
发送请求时，RADIUS客户端在收到有效响应或请求超时之前，不得重用源IP地址和源UDP端口的标识符。客户端应通过最近使用最少（LRU）方法为特定源IP地址和源UDP端口分配标识符。
RADIUS clients do not have to perform duplicate detection. When a client sends a request, it processes the first response that has a valid Response Authenticator as defined in [RFC2865] Section 3. Any later responses MUST be silently discarded, as they do not match a pending request. That is, later responses are treated exactly the same as unsolicited responses, and are silently discarded.
RADIUS客户端不必执行重复检测。当客户端发送请求时，它将处理具有[RFC2865]第3节中定义的有效响应验证器的第一个响应。任何后续响应都必须以静默方式丢弃，因为它们与挂起的请求不匹配。也就是说，以后的响应与未经请求的响应完全相同，并且被默默地丢弃。
Some RADIUS server implementations are not robust in response to overload, dropping packets with even probability across multiple sessions. In an overload situation, this results in a high failure rate for multi-round authentication protocols such as EAP [RFC3579]. Typically, users will continually retry in an attempt to gain access, increasing the load even further.
一些RADIUS服务器实现对过载的响应不够健壮，在多个会话中丢弃数据包的概率甚至不高。在过载情况下，这会导致多轮身份验证协议（如EAP[RFC3579]）的高故障率。通常，用户会不断重试以获得访问权限，从而进一步增加负载。
A more sensible approach is for a RADIUS server to preferentially accept RADIUS Access-Request packets containing a valid State attribute, so that multi-round authentication conversations, once begun, will be more likely to succeed. Similarly, a server that is proxying requests should preferentially process Access-Accept, Access-Challenge, or Access-Reject packets from home servers before processing new requests from a NAS.
一种更明智的方法是RADIUS服务器优先接受包含有效状态属性的RADIUS访问请求数据包，这样多轮身份验证对话一旦开始，就更有可能成功。类似地，代理请求的服务器应优先处理来自家庭服务器的访问接受、访问质询或访问拒绝数据包，然后再处理来自NAS的新请求。
These methods will allow some users to gain access to the network, reducing the load created by ongoing access attempts.
这些方法将允许一些用户访问网络，从而减少正在进行的访问尝试所造成的负载。
[RFC2866] indicates that Acct-Input-Octets, Acct-Output-Octets, Acct-Session-Time, Acct-Input-Packets, Acct-Output-Packets and Acct-Terminate-Cause attributes "can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop".
[RFC2866]表示账户输入八位字节、账户输出八位字节、账户会话时间、账户输入数据包、账户输出数据包和账户终止原因属性“只能出现在账户状态类型设置为停止的会计请求记录中”。
However [RFC2869] Section 2.1 states:
但是[RFC2869]第2.1节规定：
It is envisioned that an Interim Accounting record (with Acct-Status-Type = Interim-Update (3)) would contain all of the attributes normally found in an Accounting Stop message with the exception of the Acct-Term-Cause attribute.
可以设想，临时会计记录（账户状态类型=临时更新（3））将包含通常在会计停止消息中找到的所有属性，但账户期限原因属性除外。
Although [RFC2869] does not indicate that it updates [RFC2866], this is an oversight, and the above attributes are allowable in an Interim Accounting record.
尽管[RFC2869]没有表示它更新了[RFC2866]，但这是一个疏忽，并且上述属性在临时会计记录中是允许的。
[RFC2866] Section 5.5 describes Acct-Session-Id as Text within the figure summarizing the attribute format, but then goes on to state that "The String field SHOULD be a string of UTF-8 encoded 10646 characters".
[RFC2866]第5.5节将Acct会话Id描述为总结属性格式的图中的文本，但随后指出“字符串字段应为UTF-8编码的10646个字符的字符串”。
[RFC2865] defines the Text type as "containing UTF-8 encoded 10646 characters", which is compatible with the description of Acct-Session-Id. Since other attributes are consistently described as "Text" within both the figure summarizing the attribute format, and the following attribute definition, it appears that this is a typographical error, and that Acct-Session-Id is of type Text, and not of type String.
[RFC2865]将文本类型定义为“包含UTF-8编码的10646个字符”，这与Acct-Session-Id的描述兼容。由于在汇总属性格式的图形和以下属性定义中，其他属性始终被描述为“文本”，因此这似乎是一个印刷错误，该帐户会话Id的类型为Text，而不是String。
The definition of the Acct-Multi-Session-Id attribute also has typographical errors. It says:
Acct Multi Session Id属性的定义也存在印刷错误。它说：
A summary of the Acct-Session-Id attribute format ...
帐户会话Id属性格式的摘要。。。
This text should read:
案文应改为：
A summary of the Acct-Multi-Session-Id attribute format ...
Acct多会话Id属性格式的摘要。。。
The Acct-Multi-Session-Id attribute is also defined as being of type String. However, the language in the text strongly recommends that implementors consider the attribute as being of type Text. It is unclear why the type String was chosen for this attribute when the type Text would be sufficient. This attribute SHOULD be treated as Text.
Acct多会话Id属性也定义为字符串类型。然而，文本中的语言强烈建议执行者将属性视为文本类型。不清楚为什么在类型文本足够时为该属性选择类型字符串。此属性应视为文本。
[RFC2866] Section 4.1 states:
[RFC2866]第4.1节规定：
The Request Authenticator of an Accounting-Request contains a 16- octet MD5 hash value calculated according to the method described in "Request Authenticator" above.
记帐请求的请求验证器包含根据上面“请求验证器”中描述的方法计算的16位字节MD5哈希值。
However, the text does not indicate any action to take when an Accounting-Request packet contains an invalid Request Authenticator. The following text should be considered to be part of the above description:
但是，当记帐请求数据包包含无效的请求验证器时，文本不指示要采取的任何操作。以下文本应视为上述说明的一部分：
The Request Authenticator field MUST contain the correct data, as given by the above calculation. Invalid packets are silently discarded. Note that some early implementations always set the Request Authenticator to all zeros. New implementations of RADIUS clients MUST use the above algorithm to calculate the Request Authenticator field. New RADIUS server implementations MUST silently discard invalid packets.
请求验证器字段必须包含上述计算给出的正确数据。无效的数据包将被自动丢弃。注意，一些早期的实现总是将请求验证器设置为全零。RADIUS客户端的新实现必须使用上述算法来计算请求验证器字段。新的RADIUS服务器实现必须以静默方式丢弃无效数据包。
[RFC2869] Section 2.1 states:
[RFC2869]第2.1节规定：
It is also possible to statically configure an interim value on the NAS itself. Note that a locally configured value on the NAS MUST override the value found in an Access-Accept.
还可以在NAS本身上静态配置临时值。请注意，NAS上本地配置的值必须覆盖Access Accept中的值。
This requirement may be phrased too strongly. It is conceivable that a NAS implementation has a setting for a "minimum" value of Interim-Accounting-Interval, based on resource constraints in the NAS, and
这一要求的措辞可能过于强烈。可以想象，NAS实现具有基于NAS中的资源约束的临时记帐间隔的“最小”值的设置，以及
network loading in the local environment of the NAS. In such cases, the value administratively provisioned in the NAS should not be over-ridden by a smaller value from an Access-Accept message. The NAS's value could be over-ridden by a larger one, however. The intent is that the NAS sends accounting information at fixed intervals that are short enough so that the potential loss of billable revenue is limited, but also that the accounting updates are infrequent enough so that the NAS, network, and RADIUS server are not overloaded.
NAS本地环境中的网络加载。在这种情况下，NAS中管理配置的值不应被Access Accept消息中的较小值覆盖。然而，NAS的价值可能会被更大的价值所压倒。其目的是NAS以足够短的固定时间间隔发送记帐信息，以限制计费收入的潜在损失，同时也确保记帐更新的频率足够低，以避免NAS、网络和RADIUS服务器过载。
The RADIUS Authentication and Authorization Client MIB module ([RFC2618] [RFC4668]) includes counters of packet statistics. In the descriptive text of the MIB module, formulas are provided for certain counter objects. Implementors have noted apparent inconsistencies in the formulas that could result in negative values.
RADIUS身份验证和授权客户端MIB模块（[RFC2618][RFC4668]）包括数据包统计的计数器。在MIB模块的描述性文本中，为某些计数器对象提供了公式。实施者注意到公式中的明显不一致可能导致负值。
Since the original MIB module specified in [RFC2618] had been widely implemented, the RADEXT WG chose not to change the object definitions or to create new ones within the revised MIB module [RFC4668]. However, this section explains the issues and provides guidance for implementors regarding the interpretation of the textual description and comments for certain MIB objects.
由于[RFC2618]中指定的原始MIB模块已广泛实施，RADEXT工作组选择不更改对象定义或在修订的MIB模块[RFC4668]中创建新的对象定义。但是，本节解释了这些问题，并为实现人员提供了有关解释某些MIB对象的文本描述和注释的指导。
The issues raised can be summarized as follows:
提出的问题可归纳如下：
Issue (1):
问题（1）：
-- TotalIncomingPackets = Accepts + Rejects + Challenges +
UnknownTypes
--
-- TotalIncomingPackets - MalformedResponses - BadAuthenticators -
-- UnknownTypes - PacketsDropped = Successfully received
--
-- AccessRequests + PendingRequests + ClientTimeouts =
-- Successfully Received
-- TotalIncomingPackets = Accepts + Rejects + Challenges +
UnknownTypes
--
-- TotalIncomingPackets - MalformedResponses - BadAuthenticators -
-- UnknownTypes - PacketsDropped = Successfully received
--
-- AccessRequests + PendingRequests + ClientTimeouts =
-- Successfully Received
It appears that the value of "Successfully Received" could be negative, since various counters are subtracted from TotalIncomingPackets that are not included in the calculation of TotalIncomingPackets.
“成功接收”的值可能为负值，因为从TotalIncomingPackets中减去了各种计数器，而TotalIncomingPackets的计算中不包括这些计数器。
It also appears that "AccessRequests + PendingRequests + ClientTimeouts = Successfully Received" should read "AccessRequests + PendingRequests + ClientTimeouts = Successfully Transmitted".
另外，“AccessRequests+PendingRequests+ClientTimeouts=成功接收”应改为“AccessRequests+PendingRequests+ClientTimeouts=成功传输”。
"TotalIncomingPackets" and "Successfully Received" are temporary variables, i.e., not objects within the MIB module. The comment text in the MIB modules is intended, therefore, to aid in understanding. What's of consequence is the consistency of values of the objects in the MIB module, and that does not appear to be impacted by the inconsistencies noted above. It does appear, however, that the "Successfully Received" variable should be labeled "Successfully Transmitted".
“TotalIncomingPackets”和“Successfully Received”是临时变量，即不是MIB模块内的对象。因此，MIB模块中的注释文本旨在帮助理解。重要的是MIB模块中对象值的一致性，这似乎不会受到上述不一致性的影响。然而，似乎“成功接收”变量应标记为“成功传输”。
In addition, the definition of Accept, Reject or Challenge counters indicates that they MUST be incremented before the message is validated. If the message is invalid, one of MalformedResponses, BadAuthenticators, or PacketsDropped counters will be additionally incremented. In that case, the first two equations are consistent, i.e., "Successfully Received" could not be negative.
此外，接受、拒绝或质询计数器的定义表明，在验证消息之前，它们必须递增。如果消息无效，则格式错误的响应、错误的身份验证程序或包被拦截的计数器之一将额外递增。在这种情况下，前两个等式是一致的，即“成功接收”不能为负。
Issue (2):
问题（2）：
It appears that the radiusAuthClientPendingRequests counter is decremented upon retransmission. That would mean a retransmitted packet is not considered as being pending, although such retransmissions can still be considered as being pending requests.
似乎radiusAuthClientPendingRequests计数器在重新传输时递减。这意味着重传的数据包不被视为挂起，尽管这样的重传仍然可以被视为挂起的请求。
The definition of this MIB object in [RFC2618] is as follows:
[RFC2618]中此MIB对象的定义如下：
The number of RADIUS Access-Request packets destined for this server that have not yet timed out or received a response. This variable is incremented when an Access-Request is sent and decremented due to receipt of an Access-Accept, Access-Reject or Access-Challenge, a timeout or retransmission.
发送到此服务器但尚未超时或未收到响应的RADIUS访问请求数据包数。当发送访问请求时，此变量递增，由于接收到访问接受、访问拒绝或访问质询、超时或重新传输而递减。
This object purports to count the number of pending request packets. It is open to interpretation whether or not retransmissions of a request are to be counted as additional pending packets. In either event, it seems appropriate to treat retransmissions consistently with respect to incrementing and decrementing this counter.
此对象旨在统计挂起的请求数据包的数量。请求的重新传输是否被视为附加的未决数据包，这是可以解释的。在这两种情况下，似乎应该按照递增和递减计数器的方式一致地处理重传。
[RFC2865] Section 5.11 states:
[RFC2865]第5.11节规定：
Zero or more Filter-Id attributes MAY be sent in an Access-Accept packet.
在访问接受数据包中可以发送零个或多个筛选器Id属性。
In practice, the behavior of a RADIUS client receiving multiple Filter-ID attributes is implementation dependent. For example, some implementations treat multiple instances of the Filter-ID attribute as alternative filters; the first Filter-ID attribute having a name matching a locally defined filter is used, and the remaining ones are discarded. Other implementations may combine matching filters.
实际上，RADIUS客户端接收多个筛选器ID属性的行为取决于实现。例如，一些实现将过滤器ID属性的多个实例视为替代过滤器；使用第一个过滤器ID属性，该属性的名称与本地定义的过滤器匹配，其余属性将被丢弃。其他实现可以结合匹配过滤器。
As a result, the interpretation of multiple Filter-ID attributes is undefined within RADIUS. The sending of multiple Filter-ID attributes within an Access-Accept SHOULD be avoided within heterogeneous deployments and roaming scenarios, where it is likely to produce unpredictable results.
因此，多个过滤器ID属性的解释在半径内未定义。在异构部署和漫游场景中，应避免在Access Accept中发送多个筛选器ID属性，因为这可能会产生不可预测的结果。
RADIUS attributes do not explicitly state whether they are optional or mandatory. Nevertheless, there are instances where RADIUS attributes need to be treated as mandatory.
半径属性不明确说明它们是可选的还是必需的。然而，在某些情况下，需要将半径属性视为强制属性。
[RFC2865] Section 1.1 states:
[RFC2865]第1.1节规定：
A NAS that does not implement a given service MUST NOT implement the RADIUS attributes for that service. For example, a NAS that is unable to offer Apple Remote Access Protocol (ARAP) service MUST NOT implement the RADIUS attributes for ARAP. A NAS MUST treat a RADIUS access-accept authorizing an unavailable service as an access-reject instead.
未实现给定服务的NAS不得实现该服务的RADIUS属性。例如，无法提供Apple远程访问协议（ARAP）服务的NAS不得实现ARAP的RADIUS属性。NAS必须将授权不可用服务的RADIUS访问接受视为访问拒绝。
With respect to the Service-Type attribute, [RFC2865] Section 5.6 says:
关于服务类型属性，[RFC2865]第5.6节规定：
This Attribute indicates the type of service the user has requested, or the type of service to be provided. It MAY be used in both Access-Request and Access-Accept packets. A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an Access-Reject had been received instead.
此属性表示用户请求的服务类型或要提供的服务类型。它可以用于访问请求和访问接受数据包。NAS不需要实现所有这些服务类型，并且必须将未知或不受支持的服务类型视为接收到访问拒绝。
[RFC2865] Section 5 states:
[RFC2865]第5节规定：
A RADIUS server MAY ignore Attributes with an unknown Type.
RADIUS服务器可能会忽略类型未知的属性。
A RADIUS client MAY ignore Attributes with an unknown Type.
RADIUS客户端可能会忽略类型未知的属性。
With respect to Vendor-Specific Attributes (VSAs), [RFC2865] Section 5.26 states:
关于供应商特定属性（VSA），[RFC2865]第5.26节规定：
Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode.
未配备解释客户发送的供应商特定信息的服务器必须忽略该信息（尽管可能会报告）。未收到所需供应商特定信息的客户机应尝试在没有供应商特定信息的情况下运行，尽管他们可能会在降级模式下这样做（并报告他们正在这样做）。
It is possible for either a standard attribute or a VSA to represent a request for an unavailable service. However, where the Type, Vendor-ID, or Vendor-Type is unknown, a RADIUS client will not know whether or not the attribute defines a service.
标准属性或VSA都可以表示对不可用服务的请求。但是，如果类型、供应商ID或供应商类型未知，RADIUS客户端将不知道该属性是否定义了服务。
In general, it is best for a RADIUS client to err on the side of caution. On receiving an Access-Accept including an attribute of known Type for an unimplemented service, a RADIUS client MUST treat it as an Access-Reject, as directed in [RFC2865] Section 1.1. On receiving an Access-Accept including an attribute of unknown Type, a RADIUS client SHOULD assume that it is a potential service definition, and treat it as an Access-Reject. Unknown VSAs SHOULD be ignored by RADIUS clients.
一般来说，RADIUS客户端最好谨慎行事。根据[RFC2865]第1.1节的指示，在接收到包含未实现服务的已知类型属性的访问接受时，RADIUS客户端必须将其视为访问拒绝。在接收到包含未知类型属性的访问接受时，RADIUS客户端应假定它是一个潜在的服务定义，并将其视为访问拒绝。RADIUS客户端应忽略未知VSA。
In order to avoid introducing changes in default behavior, existing implementations that do not obey this recommendation should make the behavior configurable, with the legacy behavior being enabled by default. A configuration flag such as "treat unknown attributes as reject" can be exposed to the system administrator. If the flag is set to true, then Access-Accepts containing unknown attributes are treated as Access-Rejects. If the flag is set to false, then unknown attributes in Access-Accepts are silently ignored.
为了避免在默认行为中引入更改，不遵守此建议的现有实现应使行为可配置，并默认启用遗留行为。可以向系统管理员公开配置标志，例如“将未知属性视为拒绝”。如果该标志设置为true，则包含未知属性的访问接受将被视为访问拒绝。如果该标志设置为false，则Access Accepts中的未知属性将被静默忽略。
On receiving a packet including an attribute of unknown Type, RADIUS authentication server implementations SHOULD ignore such attributes. However, RADIUS accounting server implementations typically do not need to understand attributes in order to write them to stable storage or pass them to the billing engine. Therefore, accounting server implementations SHOULD be equipped to handle unknown attributes.
在接收到包含未知类型属性的数据包时，RADIUS身份验证服务器实现应忽略此类属性。但是，RADIUS accounting server实现通常不需要了解属性，就可以将其写入稳定存储或传递给计费引擎。因此，应配备记帐服务器实现来处理未知属性。
To avoid misinterpretation of service requests encoded within VSAs, RADIUS servers SHOULD NOT send VSAs containing service requests to RADIUS clients that are not known to understand them. For example, a RADIUS server should not send a VSA encoding a filter without knowledge that the RADIUS client supports the VSA.
为了避免对VSA中编码的服务请求的误解，RADIUS服务器不应将包含服务请求的VSA发送给不了解它们的RADIUS客户端。例如，RADIUS服务器不应在不知道RADIUS客户端支持VSA的情况下发送编码筛选器的VSA。
The intent of an Access-Reject is to deny access to the requested service. [RFC2865] Section 2 states:
拒绝访问的目的是拒绝访问请求的服务。[RFC2865]第2节规定：
If any condition is not met, the RADIUS server sends an "Access-Reject" response indicating that this user request is invalid. If desired, the server MAY include a text message in the Access-Reject which MAY be displayed by the client to the user. No other Attributes (except Proxy-State) are permitted in an Access-Reject.
如果不满足任何条件，RADIUS服务器将发送“访问拒绝”响应，指示此用户请求无效。如果需要，服务器可以在访问拒绝中包括文本消息，该文本消息可以由客户端向用户显示。访问拒绝中不允许有其他属性（代理状态除外）。
This text makes it clear that RADIUS does not allow the provisioning of services within an Access-Reject. If the desire is to allow limited access, then an Access-Accept can be sent with attributes provisioning limited access. Attributes within an Access-Reject are restricted to those necessary to route the message (e.g., Proxy-State), attributes providing the user with an indication that access has been denied (e.g., an EAP-Message attribute containing an EAP-Failure), or attributes conveying an error message (e.g., a Reply-Message or Error-Cause attribute).
本文明确指出，RADIUS不允许在访问拒绝中提供服务。如果希望允许有限访问，那么可以发送带有设置有限访问的属性的访问接受。访问拒绝中的属性仅限于路由消息所必需的属性（例如，代理状态）、向用户提供访问被拒绝指示的属性（例如，包含EAP故障的EAP消息属性）或传递错误消息的属性（例如，回复消息或错误原因属性）。
Unfortunately, there are examples where this requirement has been misunderstood. [RFC2869] Section 2.2 states:
不幸的是，在一些例子中，这一要求被误解了。[RFC2869]第2.2节规定：
If that authentication fails, the RADIUS server should return an Access-Reject packet to the NAS, with optional Password-Retry and Reply-Messages attributes. The presence of Password-Retry indicates the ARAP NAS MAY choose to initiate another challenge-response cycle...
如果身份验证失败，RADIUS服务器应向NAS返回访问拒绝数据包，并带有可选的密码重试和回复消息属性。密码重试表示ARAP NAS可能选择启动另一个质询响应周期。。。
This paragraph is problematic from two perspectives. Firstly, a Password-Retry attribute is being returned in an Access-Reject; this attribute does not fit into the categories established in [RFC2865]. Secondly, an Access-Reject packet is being sent in the context of a continuing authentication conversation; [RFC2865] requires use of an Access-Challenge for this. [RFC2869] uses the phrase "challenge-response" to describe this use of Access-Reject, indicating that the semantics of Access-Challenge are being used.
这一段从两个角度来看是有问题的。首先，在访问拒绝中返回密码重试属性；此属性不适合[RFC2865]中建立的类别。第二，在持续认证会话的上下文中发送接入拒绝分组；[RFC2865]需要为此使用访问质询。[RFC2869]使用短语“质询响应”来描述访问拒绝的这种用法，表示正在使用访问质询的语义。
[RFC2865] Section 4.4 addresses the semantics of Access-Challenge being equivalent to Access-Reject in some cases:
[RFC2865]第4.4节阐述了访问质询的语义，在某些情况下，访问质询等同于访问拒绝：
If the NAS does not support challenge/response, it MUST treat an Access-Challenge as though it had received an Access-Reject instead.
如果NAS不支持质询/响应，则必须将访问质询视为已收到访问拒绝。
While it is difficult to correct existing deployments of [RFC2869], we make the following recommendations:
虽然很难纠正[RFC2869]的现有部署，但我们提出以下建议：
[1] New RADIUS specifications and implementations MUST NOT use Access-Reject where the semantics of Access-Challenge are intended.
[1] 新的RADIUS规范和实现不得在预期访问质询语义的地方使用访问拒绝。
[2] Access-Reject MUST mean denial of access to the requested service. In response to an Access-Reject, the NAS MUST NOT send any additional Access-Request packets for that user session.
[2] 拒绝访问必须意味着拒绝访问请求的服务。为响应访问拒绝，NAS不得为该用户会话发送任何额外的访问请求数据包。
[3] New deployments of ARAP [RFC2869] SHOULD use Access-Challenge instead of Access-Reject packets in the conversations described in [RFC2869] Section 2.2.
[3] ARAP[RFC2869]的新部署应在[RFC2869]第2.2节所述的对话中使用访问质询而不是访问拒绝数据包。
We also note that the table of attributes in [RFC2869] Section 5.19 has an error for the Password-Retry attribute. It says:
我们还注意到[RFC2869]第5.19节中的属性表中有一个密码重试属性错误。它说：
Request Accept Reject Challenge # Attribute 0 0 0-1 0 75 Password-Retry
请求接受拒绝质询#属性0-1 0 75密码重试
However, the text in [RFC2869], Section 2.3.2 says that Password-Retry can be included within an Access-Challenge packet for EAP authentication sessions. We recommend a correction to the table that removes the "0-1" from the Reject column, and moves it to the Challenge column. We also add a "Note 2" to follow the existing "Note 1" in the document to clarify the use of this attribute.
然而，[RFC2869]第2.3.2节中的文本指出，密码重试可以包含在EAP身份验证会话的访问质询包中。我们建议对表格进行更正，从拒绝列中删除“0-1”，并将其移动到质询列。我们还在文档中现有的“注释1”后面添加了一个“注释2”，以澄清此属性的使用。
Request Accept Reject Challenge # Attribute 0 0 0 0-1 75 Password-Retry [Note 2]
请求接受拒绝质询#属性0-1 75密码重试[注2]
[Note 2] As per RFC 3579, the use of the Password-Retry in EAP authentications is deprecated. The Password-Retry attribute can be used only for ARAP authentication.
[注意2]根据RFC 3579，不推荐在EAP身份验证中使用密码重试。密码重试属性只能用于ARAP身份验证。
RADIUS has been deployed for purposes outside network access authentication, authorization, and accounting. For example, RADIUS has been deployed as a "back-end" for authenticating Voice Over IP (VOIP) connections, Hypertext Transfer Protocol (HTTP) sessions (e.g., Apache), File Transfer Protocol (FTP) sessions (e.g., proftpd), and machine logins for multiple operating systems (e.g., bsdi, pam, and gina). In those contexts, an Access-Reject sent to the RADIUS client MUST be interpreted as a rejection of the request for service, and the RADIUS client MUST NOT offer that service to the user.
RADIUS已部署用于网络访问之外的身份验证、授权和记帐。例如，RADIUS被部署为“后端”，用于验证IP语音（VOIP）连接、超文本传输协议（HTTP）会话（如Apache）、文件传输协议（FTP）会话（如proftpd）以及多个操作系统（如bsdi、pam和gina）的机器登录。在这些上下文中，发送到RADIUS客户端的访问拒绝必须解释为拒绝服务请求，RADIUS客户端不得向用户提供该服务。
For example, when an authentication failure occurs in the context of an FTP session, the normal semantics for rejecting FTP services apply. The rejection does not necessarily cause the FTP server to terminate the underlying TCP connection, but the FTP server MUST NOT offer any services protected by user authentication.
例如，当FTP会话上下文中发生身份验证失败时，拒绝FTP服务的正常语义适用。拒绝不一定会导致FTP服务器终止底层TCP连接，但FTP服务器不得提供任何受用户身份验证保护的服务。
Users may request multiple services from the NAS. Where those services are independent, the deployment MUST treat the RADIUS sessions as being independent.
用户可以从NAS请求多个服务。如果这些服务是独立的，部署必须将RADIUS会话视为独立的。
For example, a NAS may offer multi-link services where a user may have multiple simultaneous network connections. In that case, an Access-Reject for a later multi-link connection request does not necessarily mean that earlier multi-link connections are torn down. Similarly, if a NAS offers both dialup and VOIP services, the rejection of a VOIP attempt does not mean that the dialup session is torn down.
例如，NAS可以提供多链路服务，其中用户可以同时拥有多个网络连接。在这种情况下，稍后的多链路连接请求的访问拒绝并不一定意味着先前的多链路连接被中断。类似地，如果NAS同时提供拨号和VOIP服务，拒绝VOIP尝试并不意味着拨号会话中断。
Since Link-Local addresses are unique only on the local link, if the NAS and RADIUS server are not on the same link, then an IPv6 Link-Local address [RFC4862] or an IPv4 Link-Local Address [RFC3927] cannot be used to uniquely identify the NAS. A NAS SHOULD NOT utilize a link-scope address within a NAS-IPv6-Address or NAS-IP-Address attribute. A RADIUS server receiving a NAS-IPv6-Address or NAS-IP-Address attribute containing a Link-Local address SHOULD NOT count such an attribute toward satisfying the requirements of [RFC3162] Section 2.1:
由于链路本地地址仅在本地链路上是唯一的，因此如果NAS和RADIUS服务器不在同一链路上，则IPv6链路本地地址[RFC4862]或IPv4链路本地地址[RFC3927]不能用于唯一标识NAS。NAS不应使用NAS-IPv6-address或NAS IP address属性中的链路作用域地址。接收包含链路本地地址的NAS-IPv6-Address或NAS IP Address属性的RADIUS服务器不应将此类属性计入满足[RFC3162]第2.1节：
NAS-IPv6-Address and/or NAS-IP-Address MAY be present in an Access-Request packet; however, if neither attribute is present then NAS-Identifier MUST be present.
NAS-IPv6地址和/或NAS IP地址可存在于接入请求分组中；但是，如果两个属性都不存在，则必须存在NAS标识符。
There are situations in which a RADIUS client or server may have multiple addresses. For example, a dual stack host can have both IPv4 and IPv6 addresses; a host that is a member of multiple VLANs could have IPv4 and/or IPv6 addresses on each VLAN; a host can have multiple IPv4 or IPv6 addresses on a single interface. However, [RFC2865] Section 5.44 only permits zero or one NAS-IP-Address attributes within an Access-Request, and [RFC3162] Section 3 only permits zero or one NAS-IPv6-Address attributes within an Access-Request. When a NAS has more than one global address and no ability to determine which is used for identification in a particular
在某些情况下，RADIUS客户端或服务器可能有多个地址。例如，双栈主机可以同时具有IPv4和IPv6地址；作为多个VLAN成员的主机可以在每个VLAN上具有IPv4和/或IPv6地址；一台主机在一个接口上可以有多个IPv4或IPv6地址。但是，[RFC2865]第5.44节仅允许访问请求中的零或一个NAS IP地址属性，[RFC3162]第3节仅允许访问请求中的零或一个NAS-IPv6-Address属性。当NAS具有多个全局地址且无法确定在特定网络中用于标识的全局地址时
request, it is RECOMMENDED that the NAS include the NAS-Identifier attribute in an Access-Request in order to identify itself to the RADIUS server.
请求时，建议NAS在访问请求中包含NAS标识符属性，以便向RADIUS服务器标识自身。
[RFC2865] Section 3 states:
[RFC2865]第3节规定：
A RADIUS server MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that RADIUS requests can be proxied.
RADIUS服务器必须使用RADIUS UDP数据包的源IP地址来决定使用哪个共享密钥，以便可以代理RADIUS请求。
Therefore, if a RADIUS client sends packets from more than one source address, a shared secret will need to be configured on both the client and server for each source address.
因此，如果RADIUS客户端从多个源地址发送数据包，则需要在客户端和服务器上为每个源地址配置共享密钥。
With respect to the Idle-Timeout attribute, [RFC2865] Section 5.28 states:
关于空闲超时属性，[RFC2865]第5.28节规定：
This Attribute sets the maximum number of consecutive seconds of idle connection allowed to the user before termination of the session or prompt. This Attribute is available to be sent by the server to the client in an Access-Accept or Access-Challenge.
此属性设置在会话或提示终止之前允许用户的最大连续空闲连接秒数。此属性可由服务器在访问接受或访问质询中发送给客户端。
[RFC3580] Section 3.12 states:
[RFC3580]第3.12节规定：
The Idle-Timeout attribute is described in [RFC2865]. For IEEE 802 media other than 802.11 the media are always on. As a result the Idle-Timeout attribute is typically only used with wireless media such as IEEE 802.11. It is possible for a wireless device to wander out of range of all Access Points. In this case, the Idle-Timeout attribute indicates the maximum time that a wireless device may remain idle.
[RFC2865]中描述了空闲超时属性。对于802.11以外的IEEE 802媒体，媒体始终处于打开状态。因此，空闲超时属性通常仅用于无线媒体，如IEEE 802.11。无线设备可能会偏离所有接入点的范围。在这种情况下，Idle Timeout属性表示无线设备可能保持空闲的最长时间。
In the above paragraphs "idle" may not necessarily mean "no traffic"; the NAS may support filters defining what traffic is included in the idle time determination. As a result, an "idle connection" is defined by local policy in the absence of other attributes.
在上述段落中，“空闲”不一定意味着“无交通”；NAS可能支持定义空闲时间确定中包括哪些流量的过滤器。因此，“空闲连接”由本地策略在没有其他属性的情况下定义。
[RFC3748] Section 5.1 states:
[RFC3748]第5.1节规定：
If the Identity is unknown, the Identity Response field should be zero bytes in length.
如果标识未知，则标识响应字段的长度应为零字节。
However, [RFC2865] Section 5.1 describes the User-Name attribute as follows:
但是，[RFC2865]第5.1节对用户名属性的描述如下：
The String field is one or more octets.
字符串字段是一个或多个八位字节。
How should the RADIUS client behave if it receives an EAP-Response/Identity that is zero octets in length?
如果RADIUS客户端接收到长度为零八位字节的EAP响应/标识，它应该如何工作？
[RFC2865] Section 5.1 states:
[RFC2865]第5.1节规定：
This Attribute indicates the name of the user to be authenticated. It MUST be sent in Access-Request packets if available.
此属性表示要验证的用户的名称。如果可用，必须在访问请求数据包中发送。
This suggests that the User-Name attribute may be omitted if it is unavailable.
这表明，如果用户名属性不可用，则可以省略该属性。
However, [RFC3579] Section 2.1 states:
但是，[RFC3579]第2.1节规定：
In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request.
为了允许非EAP感知RADIUS代理转发访问请求数据包，如果NAS最初向对等方发送EAP请求/标识消息，NAS必须将从对等方接收的EAP响应/标识的类型数据字段的内容复制到用户名属性中，并且必须在每个后续访问请求的用户名属性中包含EAP响应/标识的类型数据字段。
This suggests that the User-Name attribute should contain the contents of the Type-Data field of the EAP-Response/Identity, even if it is zero octets in length.
这表明用户名属性应包含EAP响应/标识的类型数据字段的内容，即使其长度为零个八位字节。
Note that [RFC4282] does not permit a Network Access Identifier (NAI) of zero octets, so that an EAP-Response/Identity with a Type-Data field of zero octets MUST NOT be construed as a request for privacy (e.g., anonymous NAI).
注意，[RFC4282]不允许使用零个八位字节的网络访问标识符（NAI），因此类型数据字段为零个八位字节的EAP响应/标识不得解释为隐私请求（例如，匿名NAI）。
When a NAS receives an EAP-Response/Identity with a Type-Data field that is zero octets in length, it is RECOMMENDED that it either omit the User-Name attribute in the Access-Request or include the Calling-Station-Id in the User-Name attribute, along with a Calling-Station-Id attribute.
当NAS接收到EAP响应/标识的类型数据字段长度为零个八位字节时，建议在访问请求中省略用户名属性，或在用户名属性中包含呼叫站Id以及呼叫站Id属性。
Some implementations do not correctly handle the receipt of RADIUS responses after retransmissions. [RFC2865] Section 2.5 states:
某些实现无法正确处理重新传输后RADIUS响应的接收。[RFC2865]第2.5节规定：
If the NAS is retransmitting a RADIUS request to the same server as before, and the attributes haven't changed, you MUST use the same Request Authenticator, ID, and source port. If any attributes have changed, you MUST use a new Request Authenticator and ID.
如果NAS与以前一样将RADIUS请求重新传输到同一服务器，并且属性没有更改，则必须使用相同的请求验证器、ID和源端口。如果任何属性已更改，则必须使用新的请求验证器和ID。
Note that changing the Request ID for a retransmission may have undesirable side effects. Since RADIUS does not have a clear definition of a "session", it is perfectly valid for a RADIUS server to treat a retransmission as a new session request, and to reject it due to, for example, the enforcement of restrictions on multiple simultaneous logins.
注意，更改重传的请求ID可能会产生不良的副作用。由于RADIUS没有“会话”的明确定义，因此RADIUS服务器将重传视为新的会话请求并拒绝它是完全有效的，例如，对多个同时登录实施限制。
In that situation, the NAS may receive a belated Access-Accept for the first request, and an Access-Reject for the retransmitted request, both of which apply to the same "session".
在这种情况下，NAS可能会收到第一个请求的延迟访问接受和重传请求的访问拒绝，两者都适用于相同的“会话”。
We suggest that the contents of Access-Request packets SHOULD NOT be changed during retransmissions. If they must be changed due to the inclusion of an Event-Timestamp attribute, for example, then responses to earlier transmissions MUST be silently discarded. Any response to the current request MUST be treated as the definitive response, even if as noted above, it disagrees with earlier responses.
我们建议在重传期间不应更改访问请求数据包的内容。例如，如果由于包含事件时间戳属性而必须更改它们，则必须以静默方式放弃对早期传输的响应。对当前请求的任何响应必须视为最终响应，即使如上所述，它与先前的响应不一致。
This problem can be made worse by implementations that use a fixed retransmission timeout (30 seconds is common). We reiterate the suggestions in Section 2.1 about using congestive backoff. In that case, responses to earlier transmissions MAY be used as data points for congestive backoff, even if their contents are discarded.
使用固定重传超时（通常为30秒）的实现可能会使此问题变得更糟。我们重申第2.1节中关于使用拥挤退避的建议。在这种情况下，对早期传输的响应可以用作拥塞退避的数据点，即使其内容被丢弃。
[RFC3162] Section 2.3 says:
[RFC3162]第2.3节规定：
This Attribute indicates an IPv6 prefix (and corresponding route) to be configured for the user. It MAY be used in Access-Accept packets, and can appear multiple times. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer these prefix(es), but the server is not required to honor the hint. Since it is assumed that the NAS will plumb a route corresponding to the prefix, it is not necessary for the server to also send a Framed-IPv6-Route attribute for the same prefix.
此属性表示要为用户配置的IPv6前缀（和相应的路由）。它可以用于访问和接受数据包，并且可以多次出现。NAS可以在访问请求数据包中使用它作为向服务器发出的提示，表示它更喜欢这些前缀，但服务器不需要遵守该提示。由于假定NAS将垂直于与前缀相对应的路由，因此服务器不必也为同一前缀发送Framed-IPv6-route属性。
An Internet Service Provider (ISP) may desire to support Prefix Delegation [RFC4818] at the same time that it would like to assign a prefix for the link between the NAS and the user. The intent of the
互联网服务提供商（ISP）可能希望在为NAS和用户之间的链路分配前缀的同时支持前缀委派[RFC4818]。政府的意图
paragraph was to enable the NAS to advertise the prefix (such as via a Router Advertisement). If the Framed-Routing attribute is used, it is also possible that the prefix would be advertised in a routing protocol such as Routing Information Protocol Next Generation (RIPNG). RFC 2865 Section 5.10 describes the purpose of Framed-Routing:
第段是为了使NAS能够公布前缀（例如通过路由器公布）。如果使用帧路由属性，则前缀也可能在路由协议（如下一代路由信息协议（RIPNG））中公布。RFC 2865第5.10节描述了框架布线的目的：
This Attribute indicates the routing method for the user, when the user is a router to a network. It is only used in Access-Accept packets.
当用户是网络的路由器时，此属性指示用户的路由方法。它仅用于访问和接受数据包。
The description of the Prefix-Length field in RFC 3162 indicates excessively wide latitude:
RFC 3162中前缀长度字段的说明表明纬度过宽：
The length of the prefix, in bits. At least 0 and no larger than 128.
前缀的长度，以位为单位。至少为0且不大于128。
This length appears too broad, because it is not clear what a NAS should do with a prefix of greater granularity than /64. For example, the Framed-IPv6-Prefix may contain a /128. This does not imply that the NAS should assign an IPv6 address to the end user, because RFC 3162 already defines a Framed-IPv6-Identifier attribute to handle the Identifier portion.
此长度看起来太宽，因为不清楚NAS在使用粒度大于/64的前缀时应该做什么。例如，帧-IPv6-Prefix可以包含a/128。这并不意味着NAS应该为最终用户分配IPv6地址，因为RFC 3162已经定义了一个Framed-IPv6-Identifier属性来处理标识符部分。
It appears that the Framed-IPv6-Prefix is used for the link between the NAS and Customer Premises Equipment (CPE) only if a /64 prefix is assigned. When a /64 or larger prefix is sent, the intent is for the NAS to send a routing advertisement containing the information present in the Framed-IPv6-Prefix attribute.
似乎只有在分配了/64前缀的情况下，才会将Framed-IPv6-Prefix用于NAS和客户场所设备（CPE）之间的链路。发送/64或更大的前缀时，NAS的目的是发送包含Framed-IPv6-prefix属性中存在的信息的路由公告。
The CPE may also require a delegated prefix for its own use, if it is decrementing the Hop Limit field of IP headers. In that case, it should be delegated a prefix by the NAS via the Delegated-IPv6-Prefix attribute [RFC4818]. If the CPE is not decrementing Hop Limit, it does not require a delegated prefix.
如果CPE正在减少IP报头的跃点限制字段，则CPE还可能需要用于其自身使用的委派前缀。在这种情况下，NAS应通过delegate-IPv6-prefix属性[RFC4818]为其委派前缀。如果CPE不减少跃点限制，则不需要委派前缀。
The contents of the State attribute are available to both the RADIUS client and observers of the RADIUS protocol. RADIUS server implementations should ensure that the State attribute does not disclose sensitive information to a RADIUS client or third parties observing the RADIUS protocol.
状态属性的内容可供RADIUS客户端和RADIUS协议的观察者使用。RADIUS服务器实施应确保State属性不会向RADIUS客户端或遵守RADIUS协议的第三方披露敏感信息。
The cache mechanism described in Section 2.2.2 is vulnerable to attacks when Access-Request packets do not contain a Message-Authenticator attribute. If the server accepts requests without a Message-Authenticator, then RADIUS packets can be trivially forged by
当访问请求数据包不包含消息验证器属性时，第2.2.2节中描述的缓存机制容易受到攻击。如果服务器在没有消息验证器的情况下接受请求，那么RADIUS数据包可以通过
an attacker. Cache entries can then be forcibly expired, negating the utility of the cache. This attack can be mitigated by following the suggestions in [RFC3579] Section 4, or by requiring the presence of Message-Authenticator, as described in Sections 2.1.1 and 2.2.2.
袭击者。然后，缓存项可以强制过期，从而使缓存的效用失效。按照[RFC3579]第4节中的建议，或要求存在消息验证器（如第2.1.1节和第2.2.2节所述），可以减轻此攻击。
Since this document describes the use of RADIUS for purposes of authentication, authorization, and accounting in a wide variety of networks, applications using these specifications are vulnerable to all of the threats that are present in other RADIUS applications. For a discussion of these threats, see [RFC2865], [RFC2607], [RFC3162], [RFC3579], and [RFC3580].
由于本文档描述了在各种网络中使用RADIUS进行身份验证、授权和记帐，因此使用这些规范的应用程序容易受到其他RADIUS应用程序中存在的所有威胁的攻击。有关这些威胁的讨论，请参阅[RFC2865]、[RFC2607]、[RFC3162]、[RFC3579]和[RFC3580]。
[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月。
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007.
[RFC4818]Salowey，J.和R.Droms，“RADIUS-IPv6-Prefix属性”，RFC 4818，2007年4月。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607]Aboba，B.和J.Vollbrecht，“漫游中的代理链接和策略实施”，RFC 2607，1999年6月。
[RFC2618] Aboba, B. and G. Zorn, "RADIUS Authentication Client MIB", RFC 2618, June 1999.
[RFC2618]Aboba，B.和G.Zorn，“RADIUS认证客户端MIB”，RFC 26181999年6月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866]Rigney，C.，“半径会计”，RFC 28662000年6月。
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869]Rigney，C.，Willats，W.，和P.Calhoun，“半径延伸”，RFC 2869，2000年6月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162]Aboba，B.，Zorn，G.和D.Mitton，“RADIUS和IPv6”，RFC 3162，2001年8月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003.
[RFC3576]Chiba，M.，Dommety，G.，Eklund，M.，Mitton，D.，和B.Aboba，“远程认证拨号用户服务（RADIUS）的动态授权扩展”，RFC 35762003年7月。
[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月。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3580]Congdon，P.，Aboba，B.，Smith，A.，Zorn，G.，和J.Roese，“IEEE 802.1X远程认证拨入用户服务（RADIUS）使用指南”，RFC 35802003年9月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展认证协议（EAP）”，RFC 3748，2004年6月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927]Cheshire，S.，Aboba，B.和E.Guttman，“IPv4链路本地地址的动态配置”，RFC 3927，2005年5月。
[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月。
[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月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[PANA] Forsberg, D., Ohba, Y.,Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", Work in Progress.
[PANA]Forsberg，D.，Ohba，Y.，Ed.，Patil，B.，Tschofenig，H.，和A.Yegin，“网络接入认证承载协议（PANA）”，正在进行中。
Acknowledgments
致谢
The authors would like to acknowledge Glen Zorn and Bernard Aboba for contributions to this document.
作者要感谢Glen Zorn和Bernard Aboba对本文件的贡献。
The alternate algorithm to [RFC3579] Section 2.6.1 that is described in Section 2.1.2 of this document was designed by Raghu Dendukuri.
本文件第2.1.2节所述[RFC3579]第2.6.1节的替代算法由Raghu Dendukuri设计。
The text discussing retransmissions in Section 2.2.1 is taken with minor edits from Section 9 of" Protocol for Carrying Authentication for Network Access (PANA)" [PANA].
第2.2.1节中讨论重传的文本摘自“承载网络访问认证（PANA）协议”[PANA]第9节中的小编辑。
Alan DeKok wishes to acknowledge the support of Quiconnect Inc., where he was employed during much of the work on this document.
Alan DeKok希望感谢Quiconnect Inc.的支持，他在本文件的大部分工作中受雇于Quiconnect Inc。
David Nelson wishes to acknowledge the support of Enterasys Networks, where he was employed during much of the work on this document.
David Nelson希望感谢Enterasys Networks的支持，他曾在该文件的大部分工作中受雇于Enterasys Networks。
Authors' Addresses
作者地址
David B. Nelson Elbrys Networks, Inc. 75 Rochester Ave., Unit 3 Portsmouth, N.H. 03801 USA
David B.Nelson Elbrys Networks，Inc.美国新罕布什尔州朴茨茅斯市罗切斯特大道75号3单元03801
Phone: +1.603.570.2636
EMail: dnelson@elbrysnetworks.com
Phone: +1.603.570.2636
EMail: dnelson@elbrysnetworks.com
Alan DeKok The FreeRADIUS Server Project http://freeradius.org/
Alan DeKok FreeRADIUS服务器项目http://freeradius.org/
EMail: aland@freeradius.org
EMail: aland@freeradius.org
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.