Internet Engineering Task Force (IETF) S. Hartman
Request for Comments: 7930 Painless Security
Updates: 6613 August 2016
Category: Experimental
ISSN: 2070-1721
Internet Engineering Task Force (IETF) S. Hartman
Request for Comments: 7930 Painless Security
Updates: 6613 August 2016
Category: Experimental
ISSN: 2070-1721
Larger Packets for RADIUS over TCP
TCP上RADIUS的较大数据包
Abstract
摘要
The RADIUS-over-TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum size limit of a RADIUS packet proves problematic. This specification extends the RADIUS-over-TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action that required IESG approval.
RFC 6614中描述的RADIUS over TLS实验为RADIUS打开了新的使用案例，其中RADIUS数据包的4096个八位组的最大大小限制被证明是有问题的。该规范扩展了RADIUS over TCP实验（RFC 6613），以允许更大的RADIUS数据包。本规范补充了其他正在进行的工作，以允许RADIUS授权信息的碎片化。本文件注册了一个新的RADIUS代码，该操作需要IESG批准。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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 7841.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第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/rfc7930.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7930.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Changes to Packet Processing . . . . . . . . . . . . . . . . 4
2.1. Status-Server Considerations . . . . . . . . . . . . . . 4
3. Forward and Backward Compatibility . . . . . . . . . . . . . 5
3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Protocol-Error Code . . . . . . . . . . . . . . . . . . . . . 7
5. Too Big Response . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Changes to Packet Processing . . . . . . . . . . . . . . . . 4
2.1. Status-Server Considerations . . . . . . . . . . . . . . 4
3. Forward and Backward Compatibility . . . . . . . . . . . . . 5
3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Protocol-Error Code . . . . . . . . . . . . . . . . . . . . . 7
5. Too Big Response . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
The experiment with Remote Authentication Dial-In User Service (RADIUS) over Transport Layer Security (TLS) [RFC6614] provides strong confidentiality and integrity for RADIUS [RFC2865]. This enhanced security has opened new opportunities for using RADIUS to convey additional authorization information. As an example, [RFC7833] describes a mechanism for using RADIUS to carry Security Assertion Markup Language (SAML) messages in RADIUS. Many attributes carried in these SAML messages will require confidentiality or integrity such as that provided by TLS.
传输层安全（TLS）[RFC6614]上的远程身份验证拨入用户服务（RADIUS）实验为RADIUS[RFC2865]提供了强大的机密性和完整性。这种增强的安全性为使用RADIUS传递额外的授权信息提供了新的机会。例如，[RFC7833]描述了一种使用RADIUS在RADIUS中传输安全断言标记语言（SAML）消息的机制。这些SAML消息中包含的许多属性都需要保密性或完整性，如TLS提供的保密性或完整性。
These new use cases involve carrying additional information in RADIUS packets. The maximum packet length of 4096 octets is proving insufficient for some SAML messages and for other structures that may be carried in RADIUS.
这些新用例涉及在RADIUS数据包中携带附加信息。事实证明，4096个八位字节的最大数据包长度对于某些SAML消息和RADIUS中可能携带的其他结构是不够的。
One approach is to fragment a RADIUS message across multiple packets at the RADIUS layer. RADIUS fragmentation [RFC7499] provides a mechanism to split authorization information across multiple RADIUS messages. That mechanism is necessary in order to split authorization information across existing unmodified proxies.
一种方法是在RADIUS层跨多个数据包对RADIUS消息进行分段。RADIUS分段[RFC7499]提供了一种机制，可将授权信息跨多个RADIUS消息进行分割。为了在现有未修改的代理之间分割授权信息，该机制是必要的。
However, there are some significant disadvantages to RADIUS fragmentation. First, RADIUS is a lock-step protocol, and only one fragment can be in transit at a time as part of a given request. Also, there is no current mechanism to discover the Path Maximum Transmission Unit (PMTU) across the entire path that the fragment will travel. As a result, fragmentation is likely both at the RADIUS layer and at the transport layer. When TCP is used, much better transport characteristics can be achieved by fragmentation only at the TCP layer. This specification provides a mechanism to achieve these better transport characteristics when TCP is used. As part of this specification, a new RADIUS code is registered.
然而，半径碎片化有一些明显的缺点。首先，RADIUS是一个锁步协议，一次只能传输一个片段作为给定请求的一部分。此外，目前还没有发现碎片将通过的整个路径上的路径最大传输单位（PMTU）的机制。因此，在半径层和传输层都可能出现碎片。使用TCP时，只有在TCP层通过分段才能实现更好的传输特性。本规范提供了一种在使用TCP时实现这些更好传输特性的机制。作为本规范的一部分，注册了新的RADIUS代码。
This specification is published as an Experimental specification because the TCP extensions to RADIUS are currently experimental. The need for this specification arises from operational experience with the TCP extensions. However, this specification introduces no new experimental evaluation criteria beyond those in the base TCP specification; this specification can be evaluated along with that one for advancement on the Standards Track.
本规范作为实验性规范发布，因为RADIUS的TCP扩展目前处于实验阶段。本规范的需要源于TCP扩展的操作经验。然而，除了基本TCP规范中的标准外，本规范没有引入新的实验评估标准；该规范可与该规范一起进行评估，以便在标准轨道上取得进展。
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]中所述进行解释。
The maximum length of a RADIUS message is increased from 4096 to 65535. A RADIUS Server implementing this specification MUST be able to receive a RADIUS packet of maximum length. Servers MAY have a maximum size over which they choose to return an error, as discussed in Section 5, rather than processing a received packet; this size MUST be at least 4096 octets.
RADIUS消息的最大长度从4096增加到65535。实现此规范的RADIUS服务器必须能够接收最大长度的RADIUS数据包。如第5节所述，服务器可能有一个最大大小，在该大小上，它们选择返回错误，而不是处理接收到的数据包；此大小必须至少为4096个八位字节。
Clients implementing this specification MUST be able to receive a RADIUS packet of maximum length; that is, clients MUST NOT close a TCP connection simply because a large packet is sent over it. Clients MAY include the Response-Length attribute defined in Section 6 to indicate the maximum size of a packet that they can successfully process. Clients MAY silently discard a packet greater than some configured size; this size MUST be at least 4096 octets. Clients MUST NOT retransmit an unmodified request whose response is larger than the client can process, as subsequent responses will likely continue to be too large.
实现此规范的客户端必须能够接收最大长度的RADIUS数据包；也就是说，客户端不能仅仅因为通过TCP连接发送大数据包就关闭TCP连接。客户端可以包括在第6节中定义的响应长度属性，以指示它们可以成功处理的数据包的最大大小。客户端可以悄悄地丢弃大于某个配置大小的数据包；此大小必须至少为4096个八位字节。客户端不得重新传输响应大于客户端可以处理的未修改请求，因为后续响应可能会继续过大。
Proxies MUST be able to receive a RADIUS packet of maximum length without closing the TCP connection. Proxies SHOULD be able to process and forward packets of maximum length. When a proxy receives a request over a transport with a 4096-octet maximum length and the proxy forwards that request over a transport with a larger maximum length, the proxy MUST include the Response-Length attribute with a value of 4096.
代理必须能够在不关闭TCP连接的情况下接收最大长度的RADIUS数据包。代理应该能够处理和转发最大长度的数据包。当代理通过最大长度为4096个八位字节的传输接收到请求，并且代理通过最大长度更大的传输转发该请求时，代理必须包含值为4096的响应长度属性。
This section extends processing of Status-Server messages as described in Sections 4.1 and 4.2 of [RFC5997].
本节扩展了状态服务器消息的处理，如[RFC5997]第4.1节和第4.2节所述。
Clients implementing this specification SHOULD include the Response-Length attribute in Status-Server requests. Servers are already required to ignore unknown attributes received in this message. By including the attribute, the client indicates how large of a response it can process to its Status-Server request. It is very unlikely that a response to Status-Server is greater than 4096 octets. However, the client also indicates support for this specification, which triggers the server behavior below.
实现此规范的客户端应在状态服务器请求中包含响应长度属性。服务器已被要求忽略此消息中接收到的未知属性。通过包含该属性，客户机指示它可以对其状态服务器请求处理多大的响应。对Status Server的响应不太可能大于4096个八位字节。但是，客户端还表示支持此规范，这将触发下面的服务器行为。
If a server implementing this specification receives a Response-Length attribute in a Status-Server request, it MUST include a Response-Length attribute indicating the maximum size request it can process in its response to the Status-Server request.
如果实现此规范的服务器在状态服务器请求中接收到响应长度属性，则它必须包含一个响应长度属性，该属性指示它在对状态服务器请求的响应中可以处理的最大大小请求。
An implementation of [RFC6613] will silently discard any RADIUS packet larger than 4096 octets and will close the TCP connection. This section provides guidelines for interoperability with these implementations. These guidelines are stated at the SHOULD level. In some environments, support for large packets will be important enough that roaming or other agreements will mandate their support. In these environments, all implementations might be required to support this specification, thus removing the need for interoperability with RFC 6613. It is likely that these guidelines will be relaxed to the MAY level and support for this specification made a requirement if RADIUS over TLS and TCP are moved to the Standards Track in the future.
[RFC6613]的实现将自动丢弃任何大于4096个八位字节的RADIUS数据包，并关闭TCP连接。本节提供了与这些实现的互操作性指南。这些指南是在“应该”级别上说明的。在某些环境中，对大数据包的支持非常重要，漫游或其他协议将强制要求他们提供支持。在这些环境中，可能需要所有实现来支持此规范，因此不需要与RFC 6613进行互操作。如果TLS和TCP上的半径将来移动到标准轨道上，这些指南可能会放宽到5月份的水平，并且对本规范的支持提出了要求。
Clients SHOULD provide configuration for the maximum size of a request sent to each server. Servers SHOULD provide configuration for the maximum size of a response sent to each client. If dynamic discovery mechanisms are supported, configuration SHOULD be provided for the default maximum size of RADIUS packets sent to clients and servers. If an implementation provides more granular configuration for some classes of dynamic resources, then the implementation SHOULD also provide configuration of default maximum packet sizes at the same granularity. As an example, an implementation that provided granular configuration for resources using a particular trust anchor or belonging to a particular roaming consortium SHOULD provide default packet size configuration at the same granularity.
客户端应为发送到每个服务器的请求的最大大小提供配置。服务器应为发送到每个客户端的响应的最大大小提供配置。如果支持动态发现机制，则应为发送到客户端和服务器的RADIUS数据包的默认最大大小提供配置。如果一个实现为某些动态资源类提供了更细粒度的配置，那么该实现还应该在相同的粒度下提供默认最大数据包大小的配置。例如，为使用特定信任锚或属于特定漫游联盟的资源提供粒度配置的实现应提供相同粒度的默认数据包大小配置。
If a client sends a request larger than 4096 octets and the TCP connection is closed without a response, the client SHOULD treat the request as if a "Request Too Big" error (Section 5) specifying a maximum size of 4096 is received. Clients or proxies sending multiple requests over a single TCP connection without waiting for responses SHOULD implement capability discovery as discussed in Section 3.2.
如果客户端发送的请求大于4096个八位字节，并且TCP连接在没有响应的情况下关闭，则客户端应将该请求视为接收到指定最大大小为4096的“请求太大”错误（第5节）。在不等待响应的情况下，通过单个TCP连接发送多个请求的客户端或代理应实现第3.2节中讨论的功能发现。
By default, a server SHOULD NOT generate a response larger than 4096 octets. The Response-Length attribute MAY be included in a request to indicate that larger responses are acceptable. Other attributes or configurations MAY be used as an indicator that large responses are likely to be acceptable.
默认情况下，服务器不应生成大于4096个八位字节的响应。响应长度属性可以包括在请求中，以指示可以接受较大的响应。其他属性或配置可作为大响应可能被接受的指标。
A proxy that implements both this specification and RADIUS fragmentation [RFC7499] SHOULD use RADIUS fragmentation when the following conditions are met:
当满足以下条件时，实现本规范和RADIUS分段[RFC7499]的代理应使用RADIUS分段：
1. A RADIUS packet is being forwarded towards a next hop whose configuration does not support a packet that large.
1. RADIUS数据包正被转发到下一跳，其配置不支持如此大的数据包。
2. RADIUS fragmentation can be used for the packet in question.
2. RADIUS碎片可用于有问题的数据包。
The interoperability challenge appears at first significant. This specification proposes to introduce behavior where new implementations will fail to function with existing implementations.
互操作性的挑战一开始似乎是重大的。本规范建议引入新实现无法与现有实现一起工作的行为。
However, these capabilities are introduced to support new use cases. If an implementation has 10000 octets of attributes to send, it cannot, in general, trim down the response to something that can be sent. Under this specification, a large packet would be generated that will be silently discarded by an existing implementation. Without this specification, no packet is generated because the required attributes cannot be sent.
然而，引入这些功能是为了支持新的用例。如果一个实现有10000个八位字节的属性要发送，那么它通常无法将响应缩减到可以发送的内容。根据该规范，将生成一个大数据包，该数据包将被现有实现悄悄地丢弃。如果没有此规范，则不会生成数据包，因为无法发送所需的属性。
The biggest risk to interoperability would be if requests and responses are expanded to include additional information that is not strictly necessary. So, avoiding creating situations where large packets are sent to existing implementations is mostly an operational matter. Interoperability is most impacted when the size of packets in existing use cases is significantly increased and least impacted when large packets are used for new use cases where the deployment is likely to require updated RADIUS implementations.
互操作性面临的最大风险是，如果请求和响应被扩展到包含严格不必要的附加信息。因此，避免创建将大数据包发送到现有实现的情况主要是一个操作问题。当现有用例中的数据包大小显著增加时，互操作性受到的影响最大，而当大型数据包用于部署可能需要更新RADIUS实现的新用例时，互操作性受到的影响最小。
There is a special challenge for proxies or clients with a high request volume. When an implementation of RFC 6613 receives a packet that is too large, it closes the connection and does not respond to any requests in process. Such a client would lose requests and might find it difficult to distinguish "Request Too Big" situations from other failures. In these cases, the discovery mechanism described in Section 3.2 can be used.
对于具有高请求量的代理或客户端，存在一个特殊的挑战。当RFC 6613的实现接收到过大的数据包时，它会关闭连接，并且不会响应处理中的任何请求。这样的客户机将丢失请求，并且可能发现很难将“请求太大”的情况与其他失败区分开来。在这些情况下，可以使用第3.2节中描述的发现机制。
Also, RFC 6613 is an experiment. Part of running that experiment is to evaluate whether additional changes are required to RADIUS. A lower bar for interoperability should apply to changes to Experimental protocols than Standard protocols.
此外，RFC6613是一个实验。运行该实验的一部分是评估是否需要对半径进行额外的更改。与标准协议相比，对实验协议的更改应采用较低的互操作性标准。
This specification provides good facilities to enable implementations to understand packet size when proxying to/from Standards Track UDP RADIUS.
该规范提供了很好的工具，使实现能够在代理到标准跟踪UDP RADIUS或从标准跟踪UDP RADIUS时了解数据包大小。
As discussed in Section 2.1, a client MAY send a Status-Server message to discover whether an authentication or accounting server supports this specification. The client includes a Response-Length attribute; this signals the server to include a Response-Length attribute indicating the maximum packet size the server can process. In this one instance, Response-Length indicates the size of a request that can be processed rather than a response.
如第2.1节所述，客户端可以发送状态服务器消息，以发现身份验证或记帐服务器是否支持此规范。客户端包括响应长度属性；这会向服务器发出信号，要求其包含一个响应长度属性，该属性指示服务器可以处理的最大数据包大小。在这个实例中，响应长度表示可以处理的请求的大小，而不是响应的大小。
This document defines a new RADIUS code, 52, called Protocol-Error. This packet code may be used in response to any request packet, such as Access-Request, Accounting-Request, CoA-Request, or Disconnect-Request. It is a response packet sent by a server to a client. The packet indicates to the client that the server is unable to process the request for some reason.
本文档定义了一个新的RADIUS代码52，称为协议错误。该分组代码可用于响应任何请求分组，例如接入请求、记帐请求、CoA请求或断开连接请求。它是服务器发送给客户机的响应包。该数据包向客户端指示服务器由于某种原因无法处理该请求。
A Protocol-Error packet MUST contain an Original-Packet-Code attribute, along with an Error-Cause attribute. Other attributes MAY be included if desired. The Original-Packet-Code contains the code from the request that generated the protocol error so that clients can disambiguate requests with different codes and the same ID. Regardless of the original packet code, the RADIUS Server calculates the Message-Authenticator attribute as if the original packet were an Access-Request packet. The identifier is copied from the original request.
协议错误数据包必须包含原始数据包代码属性以及错误原因属性。如果需要，可以包括其他属性。原始数据包代码包含产生协议错误的请求的代码，以便客户端可以使用不同的代码和相同的ID消除请求的歧义。无论原始数据包代码是什么，RADIUS服务器都会计算消息验证器属性，就像原始数据包是访问请求数据包一样。标识符是从原始请求复制的。
Clients processing Protocol-Error MUST ignore unknown or unexpected attributes.
客户端处理协议错误必须忽略未知或意外属性。
This RADIUS code is hop by hop. Proxies MUST NOT forward a Protocol-Error packet they receive.
这个半径代码是逐跳的。代理不能转发他们收到的协议错误数据包。
When a RADIUS Server receives a request that is larger than can be processed, it generates a Protocol-Error response as follows:
当RADIUS服务器接收到大于可处理的请求时，它会生成协议错误响应，如下所示：
The code is Protocol-Error.
代码是协议错误。
The Response-Length attribute MUST be included and its value is the maximum size of request that will be processed.
必须包括响应长度属性，其值是将要处理的请求的最大大小。
The Error-Cause attribute is included with a value of 601.
错误原因属性包含值601。
The Original-Packet-Code attribute is copied from the request.
原始数据包代码属性是从请求中复制的。
Clients will not typically be able to adjust and resend requests when this error is received. In some cases, the client can fall back to RADIUS fragmentation. In other cases, this code will provide for better client error reporting and will avoid retransmitting requests guaranteed to fail.
收到此错误时，客户端通常无法调整和重新发送请求。在某些情况下，客户端可以退回到RADIUS碎片化。在其他情况下，此代码将提供更好的客户端错误报告，并将避免重新传输保证失败的请求。
A new RADIUS Packet Type Code is registered in the "RADIUS Packet Type Codes" registry discussed in Section 2.1 of RFC 3575 [RFC3575]. The name is "Protocol-Error" and the code is 52.
在RFC 3575[RFC3575]第2.1节中讨论的“RADIUS数据包类型代码”注册表中注册新的RADIUS数据包类型代码。名称为“协议错误”，代码为52。
The following RADIUS attribute Type values [RFC3575] are assigned. The assignment rules in Section 10.3 of [RFC6929] are used.
分配了以下半径属性类型值[RFC3575]。使用[RFC6929]第10.3节中的分配规则。
+----------------------+-----------+--------------------------------+
| Name | Attribute | Description |
+----------------------+-----------+--------------------------------+
| Response-Length | 241.3 | An attribute of type "integer" |
| | | per Section 5 of RFC 2865 |
| | | containing maximum response |
| | | length. |
| | | |
| Original-Packet-Code | 241.4 | An integer attribute |
| | | containing the code from a |
| | | packet resulting in a |
| | | Protocol-Error response. |
+----------------------+-----------+--------------------------------+
+----------------------+-----------+--------------------------------+
| Name | Attribute | Description |
+----------------------+-----------+--------------------------------+
| Response-Length | 241.3 | An attribute of type "integer" |
| | | per Section 5 of RFC 2865 |
| | | containing maximum response |
| | | length. |
| | | |
| Original-Packet-Code | 241.4 | An integer attribute |
| | | containing the code from a |
| | | packet resulting in a |
| | | Protocol-Error response. |
+----------------------+-----------+--------------------------------+
The Response-Length attribute MAY be included in any RADIUS request. In this context, it indicates the maximum length of a response the client is prepared to receive. Values are between 4096 and 65535. The attribute MAY also be included in a response to a Status-Server message. In this case, the attribute indicates the maximum size RADIUS request that is permitted.
响应长度属性可以包含在任何RADIUS请求中。在此上下文中，它指示客户端准备接收的响应的最大长度。值介于4096和65535之间。该属性也可以包含在对状态服务器消息的响应中。在这种情况下，该属性表示允许的最大大小半径请求。
A new Error-Cause value is registered in the "Values for RADIUS Attribute 101, Error-Cause Attribute" registry at <http://www.iana.org/assignments/radius-types> for "Response Too Big" with value 601. The range of valid values for the Error-Cause attribute in the "Values for RADIUS Attribute 101, Error-Cause Attribute" registry originally defined in RFC 5176 are extended. Two new ranges are defined:
在“半径属性101的值，错误原因属性”注册表中注册了一个新的错误原因值<http://www.iana.org/assignments/radius-types>对于值为601的“响应太大”。RFC 5176中最初定义的“半径属性101的值，错误原因属性”注册表中错误原因属性的有效值范围已扩展。定义了两个新范围：
6xx fatal errors committed by a RADIUS server
RADIUS服务器犯下的6xx致命错误
7xx fatal errors committed by a RADIUS client
RADIUS客户端犯下的7xx致命错误
This specification updates [RFC6613] and will be used with [RFC6614]. When used over plain TCP, this specification creates new opportunities for an on-path attacker to impact availability. These attacks can be entirely mitigated by using TLS. If these attacks are acceptable, then this specification can be used over TCP without TLS.
本规范更新了[RFC6613]，并将与[RFC6614]一起使用。当通过普通TCP使用时，此规范为路径上的攻击者创造了影响可用性的新机会。使用TLS可以完全缓解这些攻击。如果这些攻击是可接受的，那么可以在没有TLS的TCP上使用此规范。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <http://www.rfc-editor.org/info/rfc2865>.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 2865，DOI 10.17487/RFC2865，2000年6月<http://www.rfc-editor.org/info/rfc2865>.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, DOI 10.17487/RFC3575, July 2003, <http://www.rfc-editor.org/info/rfc3575>.
[RFC3575]Aboba，B.“RADIUS（远程认证拨入用户服务）的IANA注意事项”，RFC 3575，DOI 10.17487/RFC3575，2003年7月<http://www.rfc-editor.org/info/rfc3575>.
[RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, DOI 10.17487/RFC5997, August 2010, <http://www.rfc-editor.org/info/rfc5997>.
[RFC5997]DeKok，A.，“远程身份验证拨入用户服务（RADIUS）协议中状态服务器数据包的使用”，RFC 5997，DOI 10.17487/RFC5997，2010年8月<http://www.rfc-editor.org/info/rfc5997>.
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, DOI 10.17487/RFC6613, May 2012, <http://www.rfc-editor.org/info/rfc6613>.
[RFC6613]DeKok，A.，“TCP上的半径”，RFC 6613，DOI 10.17487/RFC6613，2012年5月<http://www.rfc-editor.org/info/rfc6613>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, DOI 10.17487/RFC6614, May 2012, <http://www.rfc-editor.org/info/rfc6614>.
[RFC6614]Winter，S.，McCauley，M.，Venaas，S.，和K.Wierenga，“RADIUS的传输层安全（TLS）加密”，RFC 6614，DOI 10.17487/RFC66142012年5月<http://www.rfc-editor.org/info/rfc6614>.
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, DOI 10.17487/RFC6929, April 2013, <http://www.rfc-editor.org/info/rfc6929>.
[RFC6929]DeKok，A.和A.Lior，“远程身份验证拨入用户服务（RADIUS）协议扩展”，RFC 6929，DOI 10.17487/RFC6929，2013年4月<http://www.rfc-editor.org/info/rfc6929>.
[RFC7499] Perez-Mendez, A., Ed., Marin-Lopez, R., Pereniguez-Garcia, F., Lopez-Millan, G., Lopez, D., and A. DeKok, "Support of Fragmentation of RADIUS Packets", RFC 7499, DOI 10.17487/RFC7499, April 2015, <http://www.rfc-editor.org/info/rfc7499>.
[RFC7499]Perez Mendez，A.，Ed.，Marin Lopez，R.，Pereniguez Garcia，F.，Lopez Millan，G.，Lopez，D.，和A.DeKok，“支持RADIUS数据包碎片化”，RFC 7499，DOI 10.17487/RFC7499，2015年4月<http://www.rfc-editor.org/info/rfc7499>.
[RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML)", RFC 7833, DOI 10.17487/RFC7833, May 2016, <http://www.rfc-editor.org/info/rfc7833>.
[RFC7833]Howlett，J.，Hartman，S.，和A.Perez Mendez，Ed.，“安全断言标记语言（SAML）的RADIUS属性、绑定、配置文件、名称标识符格式和确认方法”，RFC 7833，DOI 10.17487/RFC7833，2016年5月<http://www.rfc-editor.org/info/rfc7833>.
Acknowledgements
致谢
Sam Hartman's time on this document was funded by JANET as part of Project Moonshot.
山姆·哈特曼在这份文件上的时间是由珍妮特作为登月计划的一部分资助的。
Alan DeKok provided valuable review and text for the Protocol-Error packet code.
Alan DeKok为协议错误包代码提供了有价值的评论和文本。
Alejandro Perez Mendez provided valuable review comments.
亚历杭德罗·佩雷斯·门德斯提供了宝贵的审查意见。
Author's Address
作者地址
Sam Hartman Painless Security
山姆·哈特曼无痛安全
Email: hartmans-ietf@mit.edu
Email: hartmans-ietf@mit.edu