Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 8559 FreeRADIUS
Updates: 5176, 5580 J. Korhonen
Category: Standards Track April 2019
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 8559 FreeRADIUS
Updates: 5176, 5580 J. Korhonen
Category: Standards Track April 2019
ISSN: 2070-1721
Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol
远程身份验证拨入用户服务（RADIUS）协议中的动态授权代理
Abstract
摘要
RFC 5176 defines Change-of-Authorization (CoA) and Disconnect Message (DM) behavior for RADIUS. RFC 5176 also suggests that proxying these messages is possible, but it does not provide guidance as to how that is done. This specification updates RFC 5176 to correct that omission for scenarios where networks use realm-based proxying as defined in RFC 7542. This specification also updates RFC 5580 to allow the Operator-Name attribute in CoA-Request and Disconnect-Request packets.
RFC 5176定义RADIUS的授权变更（CoA）和断开消息（DM）行为。RFC 5176还建议代理这些消息是可能的，但它没有提供如何执行的指导。本规范更新了RFC 5176，以纠正网络使用RFC 7542中定义的基于领域的代理的情况下的遗漏。本规范还更新了RFC 5580，以允许CoA请求和断开请求数据包中的操作员名称属性。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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 https://www.rfc-editor.org/info/rfc8559.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8559.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Requirements Language ......................................5
2. Problem Statement ...............................................5
2.1. Typical RADIUS Proxying ....................................5
2.2. CoA Processing .............................................6
2.3. Failure of CoA Proxying ....................................6
3. How to Perform CoA Proxying .....................................7
3.1. Changes to Access-Request and Accounting-Request Packets ...8
3.2. Proxying of CoA-Request and Disconnect-Request Packets .....9
3.3. Reception of CoA-Request and Disconnect-Request Packets ...10
3.4. Operator-NAS-Identifier ...................................11
4. Requirements ...................................................14
4.1. Requirements on Home Servers ..............................14
4.2. Requirements on Visited Networks ..........................14
4.3. Requirements on Proxies ...................................14
4.3.1. Security Requirements on Proxies ...................15
4.3.2. Filtering Requirements on Proxies ..................16
5. Functionality ..................................................17
5.1. User Login ................................................17
5.2. CoA Proxying ..............................................17
6. Security Considerations ........................................18
6.1. RADIUS Security and Proxies ...............................18
6.2. Security of the Operator-NAS-Identifier Attribute .........19
7. IANA Considerations ............................................20
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................21
Authors' Addresses ................................................21
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Requirements Language ......................................5
2. Problem Statement ...............................................5
2.1. Typical RADIUS Proxying ....................................5
2.2. CoA Processing .............................................6
2.3. Failure of CoA Proxying ....................................6
3. How to Perform CoA Proxying .....................................7
3.1. Changes to Access-Request and Accounting-Request Packets ...8
3.2. Proxying of CoA-Request and Disconnect-Request Packets .....9
3.3. Reception of CoA-Request and Disconnect-Request Packets ...10
3.4. Operator-NAS-Identifier ...................................11
4. Requirements ...................................................14
4.1. Requirements on Home Servers ..............................14
4.2. Requirements on Visited Networks ..........................14
4.3. Requirements on Proxies ...................................14
4.3.1. Security Requirements on Proxies ...................15
4.3.2. Filtering Requirements on Proxies ..................16
5. Functionality ..................................................17
5.1. User Login ................................................17
5.2. CoA Proxying ..............................................17
6. Security Considerations ........................................18
6.1. RADIUS Security and Proxies ...............................18
6.2. Security of the Operator-NAS-Identifier Attribute .........19
7. IANA Considerations ............................................20
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................21
Authors' Addresses ................................................21
RFC 5176 [RFC5176] defines Change-of-Authorization (CoA) and Disconnect Message (DM) behavior for RADIUS. Section 3.1 of [RFC5176] suggests that proxying these messages is possible, but it does not provide guidance as to how that is done. This omission means that in practice, proxying of CoA packets is impossible.
RFC 5176[RFC5176]定义RADIUS的授权变更（CoA）和断开消息（DM）行为。[RFC5176]第3.1节建议代理这些消息是可能的，但它没有提供如何进行的指导。这种省略意味着在实践中，CoA数据包的代理是不可能的。
We partially correct that omission here by explaining how proxying of these packets can be done by leveraging an existing RADIUS attribute, Operator-Name (Section 4.1 of [RFC5580]). We then explain how this attribute can be used by proxies to route packets "backwards" through a RADIUS proxy chain from a home network to a visited network. We then introduce a new attribute: Operator-NAS-Identifier. This attribute permits packets to be routed from the RADIUS server at the visited network to the Network Access Server (NAS).
我们在这里通过解释如何利用现有的RADIUS属性、操作员名称（RFC5580的第4.1节）来代理这些数据包，部分纠正了这一遗漏。然后，我们解释代理如何使用此属性通过RADIUS代理链“向后”将数据包从家庭网络路由到访问网络。然后，我们引入一个新属性：操作员NAS标识符。此属性允许将数据包从访问网络的RADIUS服务器路由到网络访问服务器（NAS）。
This correction is limited to the use case of realm-based proxying as defined in [RFC7542]. Other forms of proxying are possible but are not discussed here. We note that the recommendations provided in this document apply only to those systems that implement proxying of CoA packets, and then only to those that implement realm-based CoA proxying. This specification neither requires nor suggests changes to any implementation or deployment of any other RADIUS systems.
此更正仅限于[RFC7542]中定义的基于领域的代理的用例。其他形式的代理是可能的，但这里不讨论。我们注意到，本文档中提供的建议仅适用于那些实现CoA数据包代理的系统，然后仅适用于那些实现基于领域的CoA代理的系统。本规范既不要求也不建议对任何其他RADIUS系统的任何实施或部署进行更改。
We also update the behavior described in [RFC5580] to allow the Operator-Name attribute to be used in CoA-Request and Disconnect-Request packets, as further described in this document.
我们还更新了[RFC5580]中描述的行为，以允许在CoA请求和断开连接请求数据包中使用Operator Name属性，如本文档中所述。
This document is a Standards Track document in order to update the behavior described in [RFC5580], as [RFC5580] is also a Standards Track document. This document relies heavily upon and also updates some of the behaviors described in RFC 5176, which is an Informational document; because the applicability statements in Section 1.1 of [RFC5176] do not apply to this document, this document does not change the status of [RFC5176].
本文件为标准跟踪文件，用于更新[RFC5580]中描述的行为，因为[RFC5580]也是标准跟踪文件。本文件高度依赖并更新了RFC 5176中描述的一些行为，RFC 5176是一份信息性文件；由于[RFC5176]第1.1节中的适用性声明不适用于本文件，因此本文件不会更改[RFC5176]的状态。
We finally conclude with a discussion of the security implications of this design and show that they do not decrease the security of the network.
最后，我们讨论了这种设计的安全含义，并表明它们不会降低网络的安全性。
This document frequently uses the following terms:
本文件经常使用以下术语：
CoA
辅酶A
Change of authorization, e.g., CoA-Request, CoA-ACK, or CoA-NAK, as defined in [RFC5176]. [RFC5176] also defines Disconnect-Request, Disconnect-ACK, and Disconnect-NAK. For simplicity, where we use "CoA" in this document, we mean a generic "CoA-Request or Disconnect-Request" packet. We use "CoA-Request" or "Disconnect-Request" to refer to the specific packet types.
授权变更，如[RFC5176]中定义的CoA请求、CoA确认或CoA NAK。[RFC5176]还定义了断开请求、断开确认和断开NAK。为简单起见，在本文档中使用“CoA”时，我们指的是通用的“CoA请求或断开连接请求”数据包。我们使用“CoA请求”或“断开连接请求”来表示特定的数据包类型。
Network Access Identifier (NAI)
网络访问标识符（NAI）
The user identity submitted by the client during network access authentication. See [RFC7542]. The purpose of the NAI is to identify the user as well as assist in the routing of the authentication request. Please note that the NAI may not necessarily be the same as the user's email address or the user identity submitted in an application-layer authentication.
网络访问身份验证期间客户端提交的用户标识。见[RFC7542]。NAI的目的是识别用户以及协助认证请求的路由。请注意，NAI不一定与应用层身份验证中提交的用户电子邮件地址或用户身份相同。
Network Access Server (NAS)
网络访问服务器（NAS）
The device that clients connect to in order to get access to the network. In Point-to-Point Tunneling Protocol (PPTP) terminology, this is referred to as the PPTP Access Concentrator (PAC), and in Layer 2 Tunneling Protocol (L2TP) terminology, it is referred to as the L2TP Access Concentrator (LAC). In IEEE 802.11, it is referred to as an Access Point.
客户端为了访问网络而连接到的设备。在点对点隧道协议（PPTP）术语中，这称为PPTP访问集中器（PAC），在第二层隧道协议（L2TP）术语中，这称为L2TP访问集中器（LAC）。在IEEE 802.11中，它被称为接入点。
Home Network
家庭网络
The network that holds the authentication credentials for a user.
保存用户身份验证凭据的网络。
Visited Network
访问网络
A network other than the home network, where the user attempts to gain network access. The visited network typically has a relationship with the home network, possibly through one or more intermediary proxies.
除家庭网络以外的一种网络，用户在该网络中试图获得网络访问权。所访问的网络通常与家庭网络具有关系，可能通过一个或多个中间代理。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This section describes how RADIUS proxying works, how CoA packets work, and why CoA proxying as discussed in [RFC5176] is insufficient to create a working system.
本节介绍RADIUS代理的工作原理、CoA数据包的工作原理以及[RFC5176]中讨论的CoA代理不足以创建工作系统的原因。
When a RADIUS server proxies an Access-Request packet, it typically does so based on the contents of the User-Name attribute, which contains an NAI [RFC7542]. This specification describes how to use the NAI in order to proxy CoA packets across multiple hops. Other methods of proxying CoA packets are possible but are not discussed here.
当RADIUS服务器代理访问请求数据包时，它通常基于用户名属性的内容进行代理，该属性包含NAI[RFC7542]。本规范描述了如何使用NAI跨多个跃点代理CoA数据包。代理CoA数据包的其他方法是可能的，但这里不讨论。
In order to determine the "next hop" for a packet, the proxying server looks up the "realm" portion of the NAI in a logical Authentication, Authorization, and Accounting (AAA) routing table, as described in Section 3 of [RFC7542]. The entry in that table contains information about the next hop to which the packet is sent. This information can be IP address, shared secret, certificate, etc. The next hop may also be another proxy, or it may be the home server for that realm.
为了确定数据包的“下一跳”，代理服务器在逻辑身份验证、授权和计费（AAA）路由表中查找NAI的“领域”部分，如[RFC7542]第3节所述。该表中的条目包含有关数据包发送到的下一跳的信息。此信息可以是IP地址、共享密钥、证书等。下一个跃点也可能是另一个代理，或者可能是该领域的主服务器。
If the next hop is a proxy, that proxy will perform the same realm lookup and then proxy the packet as above. At some point, the next hop will be the home server for that realm.
如果下一个跃点是代理，则该代理将执行相同的领域查找，然后代理数据包，如上所述。在某个时刻，下一个跃点将是该领域的主服务器。
The home server validates the NAI in the User-Name attribute against the list of realms hosted by the home network. If there is no match, then an Access-Reject is returned. All other packets are processed through local site rules, which result in an appropriate response packet being sent. This response packet can be Access-Accept, Access-Challenge, or Access-Reject.
家庭服务器根据家庭网络托管的领域列表验证用户名属性中的NAI。如果不匹配，则返回访问拒绝。所有其他数据包都通过本地站点规则进行处理，从而发送适当的响应数据包。此响应数据包可以是访问接受、访问质询或访问拒绝。
The RADIUS client receiving that response packet will match it to an outstanding request. If the client is part of a proxy, the proxy will then send that response packet in turn to the system that originated the Access-Request. This process continues until the response packet arrives at the NAS.
接收到该响应数据包的RADIUS客户端将把它与未完成的请求相匹配。如果客户端是代理的一部分，那么代理将依次向发起访问请求的系统发送该响应数据包。此过程将继续，直到响应数据包到达NAS。
The proxies are typically stateful with respect to ongoing request/response packets but are stateless with respect to user sessions. That is, once a response has been sent by the proxy, it can discard all information about the request packet, other than what is needed for detecting retransmissions as per Section 2.2.2 of [RFC5080].
代理通常对于正在进行的请求/响应数据包是有状态的，但是对于用户会话是无状态的。也就是说，一旦代理发送了响应，它可以丢弃关于请求数据包的所有信息，而不是根据[RFC5080]第2.2.2节检测重传所需的信息。
The same method is used to proxy Accounting-Request packets. Proxying both Access-Request and Accounting-Request packets allows proxies to connect visited networks to home networks for all AAA purposes.
同样的方法也用于代理记帐请求数据包。代理访问请求和记帐请求数据包允许代理将访问的网络连接到家庭网络，以实现所有AAA目的。
[RFC5176] describes how CoA clients send packets to CoA servers. We note that a system comprising the CoA client is typically co-located with, or is the same as, the RADIUS server. Similarly, the CoA server is a system that is either co-located with or the same as the RADIUS client.
[RFC5176]描述CoA客户端如何向CoA服务器发送数据包。我们注意到，包含CoA客户端的系统通常与RADIUS服务器位于同一位置，或者与RADIUS服务器位于同一位置。类似地，CoA服务器是一个与RADIUS客户端位于同一位置或与RADIUS客户端位于同一位置的系统。
In the case of packets sent inside of one network, the source and destination of CoA packets are locally determined. There is thus no need for standardization of that process, as networks are free to send CoA packets whenever they want, for whatever reason they want.
在一个网络内发送数据包的情况下，本地确定CoA数据包的源和目的地。因此，无需对该过程进行标准化，因为网络可以随时自由发送CoA数据包，无论出于何种原因。
The situation is more complicated when proxies are involved. [RFC5176] suggests that CoA proxying is permitted, but [RFC5176] does not make any suggestions as to how that proxying should be done.
当涉及代理时，情况更加复杂。[RFC5176]建议允许CoA代理，但[RFC5176]未就如何进行代理提出任何建议。
If proxies were to track user sessions, it would be possible for a proxy to match an incoming CoA packet to a user session and then to proxy the CoA packet to the RADIUS client that originated the Access-Request for that session. There are many problems with such a scenario.
如果代理跟踪用户会话，则代理可以将传入的CoA数据包与用户会话匹配，然后将CoA数据包代理给发起该会话访问请求的RADIUS客户端。这种情况有很多问题。
The CoA server might not, in fact, be co-located with the RADIUS client, in which case it might not have access to user session information for performing the reverse path forwarding.
事实上，CoA服务器可能与RADIUS客户端不在同一位置，在这种情况下，它可能无法访问用于执行反向路径转发的用户会话信息。
The CoA server may be down, but there may be a different CoA server that could successfully process the packet. The CoA client should then fail over to a different CoA server. If the reverse path is restricted to be the same as the forward path, then such failover is not possible.
CoA服务器可能已关闭，但可能存在另一个可以成功处理数据包的CoA服务器。然后，CoA客户端应故障转移到不同的CoA服务器。如果反向路径被限制为与正向路径相同，则不可能进行此类故障切换。
In a roaming consortium, the proxies may forward traffic for tens of millions of users. Tracking each user session can be expensive and complicated, and doing so does not scale well. For that reason, most proxies do not record user sessions.
在漫游联盟中，代理可以为数千万用户转发流量。跟踪每个用户会话可能既昂贵又复杂，而且无法很好地扩展。因此，大多数代理不记录用户会话。
Even if the proxy recorded user sessions, [RFC5176] is silent on the topic of what attributes constitute "session identification attributes". That silence means it is impossible for a proxy to determine if a CoA packet matches a particular user session.
即使代理记录了用户会话，[RFC5176]也没有提及哪些属性构成“会话标识属性”。这种静默意味着代理无法确定CoA数据包是否与特定用户会话匹配。
The result of all of these issues is that CoA proxying is impossible when using the behavior defined in [RFC5176].
所有这些问题的结果是，当使用[RFC5176]中定义的行为时，CoA代理是不可能的。
The solution to the above problem is to use realm-based proxying on the reverse path, just as with the forward path. In order for the reverse path proxying to work, the proxy decision must be based on an attribute other than User-Name.
上述问题的解决方案是在反向路径上使用基于领域的代理，就像在正向路径上一样。为了使反向路径代理工作，代理决策必须基于用户名以外的属性。
The reverse path proxying can be done by using the Operator-Name attribute defined in Section 4.1 of [RFC5580]. We repeat a portion of that definition here for clarity:
反向路径代理可以通过使用[RFC5580]第4.1节中定义的运算符名称属性来完成。为了清楚起见，我们在此重复该定义的一部分：
This attribute carries the operator namespace identifier and the operator name. The operator name is combined with the namespace identifier to uniquely identify the owner of an access network.
此属性携带运算符名称空间标识符和运算符名称。操作员名称与名称空间标识符相结合，以唯一标识访问网络的所有者。
...followed a few paragraphs later by a description of the REALM namespace:
…在几段之后是对领域名称空间的描述：
REALM ('1' (0x31)):
领域（'1'（0x31））：
The REALM operator namespace can be used to indicate operator names based on any registered domain name. Such names are required to be unique, and the rights to use a given realm name are obtained coincident with acquiring the rights to use a particular Fully Qualified Domain Name (FQDN). ...
域运算符命名空间可用于基于任何注册域名指示运算符名称。此类名称必须是唯一的，使用给定域名的权利与获取使用特定完全限定域名（FQDN）的权利同时获得。。。
In short, the Operator-Name attribute contains an ASCII "1", followed by the realm of the visited network. For example, for the "example.com" realm, the Operator-Name attribute contains the text "1example.com". This information is precisely what is needed by intermediate nodes in order to perform CoA proxying.
简而言之，Operator Name属性包含一个ASCII“1”，后跟访问网络的域。例如，对于“example.com”领域，Operator Name属性包含文本“1example.com”。此信息正是中间节点执行CoA代理所需的信息。
The remainder of this document describes how CoA proxying can be performed by using the Operator-Name attribute. We describe the following:
本文档的其余部分描述了如何使用操作员名称属性执行CoA代理。我们描述如下：
o how the forward path has to change in order to allow reverse path proxying
o 如何更改正向路径以允许反向路径代理
o how reverse path proxying works
o 反向路径代理的工作原理
o how visited networks and home networks have to behave in order for CoA proxying to work
o 访问网络和家庭网络必须如何运行才能使代理工作
We note that as a proxied CoA packet is sent to only one destination, the Operator-Name attribute MUST NOT occur more than once in a packet. If a packet contains more than one Operator-Name, implementations MUST treat the second and subsequent attributes as "invalid attributes", as discussed in Section 2.8 of [RFC6929].
我们注意到，由于代理CoA数据包仅发送到一个目的地，因此操作员名称属性在数据包中不得出现多次。如[RFC6929]第2.8节所述，如果数据包包含多个操作员名称，则实现必须将第二个和后续属性视为“无效属性”。
When a visited network proxies an Access-Request or Accounting-Request packet outside of its network, a visited network that wishes to support realm-based CoA proxying SHOULD include an Operator-Name attribute in the packet, as discussed in Section 4.1 of [RFC5580]. The contents of the Operator-Name attribute should be "1", followed by the realm name of the visited network. Where the visited network has more than one realm name, a "canonical" name SHOULD be chosen and used for all packets.
当到访网络在其网络之外代理访问请求或记帐请求数据包时，希望支持基于领域的代理的到访网络应在数据包中包含操作员名称属性，如[RFC5580]第4.1节所述。Operator Name属性的内容应为“1”，后跟访问网络的域名。如果访问的网络有多个域名，则应选择一个“规范”名称并用于所有数据包。
Visited networks MUST use a consistent value for Operator-Name for any one user session. That is, sending "1example.com" in an Access-Request packet and "1example.org" in an Accounting-Request packet for that same session is forbidden. Such behavior would make it look like a single user session was active simultaneously in two different visited networks, which is impossible.
访问的网络必须为任何一个用户会话的操作员名称使用一致的值。也就是说，禁止在同一会话的访问请求数据包中发送“1example.com”，在记帐请求数据包中发送“1example.org”。这种行为会使单个用户会话在两个不同的访问网络中同时处于活动状态，这是不可能的。
Proxies that record user session information SHOULD also record Operator-Name. Proxies that do not record user session information do not need to record Operator-Name.
记录用户会话信息的代理还应记录操作员名称。不记录用户会话信息的代理不需要记录操作员名称。
Home networks SHOULD record Operator-Name along with any other information that they record about user sessions. Home networks that expect to send CoA packets to visited networks MUST record Operator-Name for each user session that originates from a visited network. Failure to record Operator-Name would mean that the home network would not know where to send any CoA packets.
家庭网络应记录操作员姓名以及他们记录的有关用户会话的任何其他信息。期望向到访网络发送CoA数据包的家庭网络必须记录来自到访网络的每个用户会话的操作员名称。未能记录运营商名称将意味着家庭网络不知道向何处发送任何CoA数据包。
Networks that host both the RADIUS client and RADIUS server do not need to create, record, or track Operator-Name. That is, if the visited network and home network are the same, there is no need to use the Operator-Name attribute.
承载RADIUS客户端和RADIUS服务器的网络不需要创建、记录或跟踪操作员名称。也就是说，如果访问的网络和家庭网络相同，则不需要使用操作员名称属性。
When a home network wishes to send a CoA-Request or Disconnect-Request packet to a visited network, it MUST include an Operator-Name attribute in the CoA packet. The value of the Operator-Name attribute MUST be the value that was recorded earlier for that user session.
当家庭网络希望向到访网络发送CoA请求或断开请求数据包时，必须在CoA数据包中包含操作员名称属性。Operator Name属性的值必须是先前为该用户会话记录的值。
The home network MUST look up the realm from the Operator-Name attribute in a logical "realm routing table", as discussed in Section 3 of [RFC7542]. That logical realm table is defined therein as:
家庭网络必须从逻辑“领域路由表”中的操作员名称属性中查找领域，如[RFC7542]第3节所述。该逻辑领域表在其中定义为：
... a logical AAA routing table, where the "utf8-realm" portion acts as a key, and the values stored in the table are one or more "next hop" AAA servers.
... 逻辑AAA路由表，其中“utf8领域”部分用作密钥，表中存储的值是一个或多个“下一跳”AAA服务器。
In order to support proxying of CoA packets, this table is extended to include a mapping between "utf8-realm" and one or more next-hop CoA servers.
为了支持CoA数据包的代理，此表被扩展以包括“utf8领域”和一个或多个下一跳CoA服务器之间的映射。
When proxying CoA-Request and Disconnect-Request packets, the lookups will return data from the "CoA server" field instead of the "AAA server" field.
代理CoA请求和断开请求数据包时，查找将从“CoA服务器”字段而不是“AAA服务器”字段返回数据。
In practice, this process means that CoA proxying works exactly like "normal" RADIUS proxying, except that the proxy decision is made using the realm from the Operator-Name attribute instead of using the realm from the User-Name attribute.
实际上，此过程意味着CoA代理的工作方式与“正常”半径代理的工作方式完全相同，只是代理决策是使用Operator Name属性中的领域而不是使用User Name属性中的领域做出的。
Proxies that receive the CoA packet will look up the realm from the Operator-Name attribute in a logical "realm routing table", as with home servers, above. The packet is then sent to the proxy for the realm that was found in that table. This process continues with any subsequent proxies until the packet reaches a public CoA server at the visited network.
接收CoA数据包的代理将从逻辑“领域路由表”中的Operator Name属性查找领域，与上面的家庭服务器一样。然后将数据包发送到该表中找到的领域的代理。此过程继续与任何后续代理一起进行，直到数据包到达访问网络的公共CoA服务器。
Where the realm is unknown, the proxy MUST return a NAK packet that contains an Error-Cause Attribute having value 502 ("Request Not Routable").
在领域未知的情况下，代理必须返回一个NAK数据包，该数据包包含一个值为502的错误原因属性（“请求不可路由”）。
Proxies that receive a CoA packet MUST NOT use the NAI from the User-Name attribute in order to make proxying decisions. Doing so would result in the CoA packet being forwarded to the home network, while the user's session is in the visited network.
接收CoA数据包的代理不得使用用户名属性中的NAI来做出代理决策。这样做将导致CoA分组被转发到家庭网络，而用户的会话在访问的网络中。
We also update Section 5 of [RFC5580] to permit CoA-Request and Disconnect-Request packets to contain zero or one instance of the Operator-Name attribute.
我们还更新了[RFC5580]的第5节，以允许CoA请求和断开连接请求数据包包含零个或一个操作员名称属性实例。
After some proxying, the CoA packet will be received by the CoA server in the visited network. That CoA server MUST validate the NAI in the Operator-Name attribute against the list of realms hosted by the visited network. If the realm is not found, then the CoA server MUST return a NAK packet that contains an Error-Cause Attribute having value 502 ("Request Not Routable").
在一些代理之后，访问网络中的CoA服务器将接收CoA数据包。CoA服务器必须根据访问网络托管的领域列表验证Operator Name属性中的NAI。如果未找到域，则CoA服务器必须返回一个NAK数据包，该数据包包含一个值为502的错误原因属性（“请求不可路由”）。
Some home networks will not have permission to send CoA packets to the visited network. The CoA server SHOULD therefore also validate the NAI contained in the User-Name attribute. If the home network is not permitted to send CoA packets to this visited network, then the CoA server MUST return a NAK packet that contains an Error-Cause Attribute having value 502 ("Request Not Routable").
某些家庭网络将无权向访问的网络发送CoA数据包。因此，CoA服务器还应验证用户名属性中包含的NAI。如果不允许家庭网络向该访问的网络发送CoA分组，则CoA服务器必须返回包含值为502（“请求不可路由”）的错误原因属性的NAK分组。
These checks make it more difficult for a malicious home network to scan roaming networks in order to determine which visited network hosts which realm. That information should be known to all parties in advance and exchanged via methods outside the scope of this specification. Those methods will typically be in the form of contractual relationships between parties or membership in a roaming consortium.
这些检查使得恶意家庭网络更难扫描漫游网络，以确定访问的网络主机是哪个领域。所有各方应事先了解该信息，并通过本规范范围外的方法进行交换。这些方法通常采用当事方之间的合同关系或联合体成员的形式。
The CoA server in the visited network will also ensure that the Operator-NAS-Identifier attribute is known, as described below. If the attribute matches a known NAS, then the packet will be sent to that NAS. Otherwise, the CoA server MUST return a NAK packet that contains an Error-Cause Attribute having value 403 ("NAS Identification Mismatch").
访问网络中的CoA服务器还将确保操作员NAS标识符属性已知，如下所述。如果该属性与已知NAS匹配，则数据包将被发送到该NAS。否则，CoA服务器必须返回包含错误原因属性的NAK数据包，该属性的值为403（“NAS标识不匹配”）。
All other received packets are processed as per local site rules and will result in an appropriate response packet being sent. This process mirrors the method used to process Access-Request and Accounting-Request packets (described above).
所有其他接收到的数据包按照本地站点规则进行处理，并将导致发送适当的响应数据包。此过程反映了用于处理访问请求和记帐请求数据包（如上所述）的方法。
Processing done by the visited network will normally include sending the CoA packet to the NAS, having the NAS process it, and then returning any response packets back up the proxy chain to the home server.
受访网络完成的处理通常包括将CoA数据包发送到NAS，让NAS对其进行处理，然后将任何响应数据包返回到代理链上的主服务器。
The only missing piece here is the procedure by which the visited network gets the packet from its public CoA server to the NAS. The visited network could use NAS-Identifier, NAS-IP-Address, or NAS-IPv6-Address, but these attributes may have been edited by an intermediate proxy or the attributes may be missing entirely.
这里唯一缺少的是访问网络从其公共CoA服务器获取数据包到NAS的过程。访问的网络可以使用NAS标识符、NAS IP地址或NAS-IPv6-Address，但这些属性可能已由中间代理编辑，或者这些属性可能完全丢失。
These attributes may be incorrect because proxies forwarding Access-Request packets often rewrite them for internal policy reasons. These attributes may be missing, because the visited network may not want all upstream proxies and home servers to have detailed information about the internals of its private network and may remove them itself.
这些属性可能不正确，因为转发访问请求数据包的代理经常出于内部策略原因重写它们。这些属性可能会丢失，因为访问的网络可能不希望所有上游代理和家庭服务器都有关于其专用网络内部的详细信息，并且可能会自行删除它们。
We therefore need a way to identify a NAS in the visited network via a method that affords privacy and does not use any existing attributes. Our solution is to define an Operator-NAS-Identifier attribute, which identifies an individual NAS in the visited network.
因此，我们需要一种通过提供隐私且不使用任何现有属性的方法来识别访问网络中的NAS的方法。我们的解决方案是定义一个操作员NAS标识符属性，该属性标识访问网络中的单个NAS。
The Operator-NAS-Identifier attribute is an opaque token that identifies an individual NAS in a visited network. It MAY appear in the following packets: Access-Request, Accounting-Request, CoA-Request, or Disconnect-Request. Operator-NAS-Identifier MUST NOT appear in any other packets.
Operator NAS Identifier属性是一个不透明令牌，用于标识访问网络中的单个NAS。它可能出现在以下数据包中：访问请求、记帐请求、CoA请求或断开连接请求。操作员NAS标识符不得出现在任何其他数据包中。
Operator-NAS-Identifier MAY occur in a packet if the packet also contains an Operator-Name attribute. Operator-NAS-Identifier MUST NOT appear in a packet if there is no Operator-Name in the packet. As each proxied CoA packet is sent to only one NAS, the Operator-NAS-Identifier attribute MUST NOT occur more than once in a packet. If a packet contains more than one Operator-NAS-Identifier, implementations MUST treat the second and subsequent attributes as "invalid attributes", as discussed in Section 2.8 of [RFC6929].
如果数据包还包含操作员名称属性，则数据包中可能会出现操作员NAS标识符。如果数据包中没有运营商名称，则数据包中不得出现运营商NAS标识符。由于每个代理CoA数据包仅发送到一个NAS，因此操作员NAS标识符属性在一个数据包中不得出现多次。如[RFC6929]第2.8节所述，如果数据包包含多个运营商NAS标识符，则实施必须将第二个和后续属性视为“无效属性”。
An Operator-NAS-Identifier attribute SHOULD be added to an Access-Request or Accounting-Request packet by a visited network, before proxying a packet to an external RADIUS server. When the Operator-NAS-Identifier attribute is added to a packet, the following attributes SHOULD be deleted from the packet: NAS-IP-Address, NAS-IPv6-Address, and NAS-Identifier. If these attributes are deleted, the proxy MUST then add a new NAS-Identifier attribute,
在将数据包代理到外部RADIUS服务器之前，应通过访问的网络将操作员NAS标识符属性添加到访问请求或记帐请求数据包中。将操作员NAS标识符属性添加到数据包时，应从数据包中删除以下属性：NAS IP地址、NAS-IPv6-Address和NAS标识符。如果删除了这些属性，则代理必须添加新的NAS标识符属性，
in order to satisfy the requirements of Section 4.1 of [RFC2865] and Section 4.1 of [RFC2866]. The contents of the new NAS-Identifier attribute SHOULD be the realm name of the visited network.
为了满足[RFC2865]第4.1节和[RFC2866]第4.1节的要求。新NAS标识符属性的内容应为访问网络的域名。
When a server receives a packet that already contains an Operator-NAS-Identifier attribute, no such editing is performed.
当服务器接收到已包含操作员NAS标识符属性的数据包时，不会执行此类编辑。
The Operator-NAS-Identifier attribute MUST NOT be added to any packet by any other proxy or server in the network. Only the visited network (i.e., the operator) can name a NAS that is inside of the visited network.
网络中的任何其他代理或服务器不得将操作员NAS标识符属性添加到任何数据包中。只有受访网络（即运营商）才能命名受访网络内部的NAS。
The result of these requirements is that for everyone outside of the visited network there is only one NAS: the visited network itself. Also, the visited network is able to identify its own NASes to its own satisfaction.
这些要求的结果是，对于访问网络之外的所有人，只有一个NAS：访问网络本身。此外，访问的网络能够识别自己的NASE，使其满意。
This usage of the Operator-NAS-Identifier attribute parallels the Operator-Name attribute as defined in Section 4.1 of [RFC5580].
操作员NAS标识符属性的使用与[RFC5580]第4.1节中定义的操作员名称属性平行。
The Operator-NAS-Identifier attribute is defined as follows.
操作员NAS标识符属性定义如下。
Description
描述
An opaque token describing the NAS a user has logged into.
描述用户已登录的NAS的不透明令牌。
Type
类型
241.8 (assigned by IANA from the "short extended space" [RFC6929] of the "RADIUS Attribute Types" registry).
241.8（由IANA从“半径属性类型”注册表的“短扩展空间”[RFC6929]分配）。
Length
长
4 to 35.
4至35岁。
Implementations supporting this attribute MUST be able to handle between one (1) and thirty-two (32) octets of data. Implementations creating an Operator-NAS-Identifier attribute MUST NOT create attributes with more than sixty-four (64) octets of data. A 32-octet string should be more than sufficient for future uses.
支持此属性的实现必须能够处理一（1）到三十二（32）个八位字节的数据。创建操作员NAS标识符属性的实现不能创建包含六十四（64）个八位字节以上数据的属性。一个32个八位组的字符串对于将来的使用应该是足够的。
Data Type
数据类型
The data type of this field is "string". See Section 3.5 of [RFC8044] for a definition.
此字段的数据类型为“字符串”。定义见[RFC8044]第3.5节。
Value
价值
This attribute contains an opaque token that can only be interpreted by the visited network.
此属性包含只能由访问的网络解释的不透明令牌。
This token MUST allow the visited network to direct the packet to the NAS for the user's session. In practice, this requirement means that the visited network has two practical methods for creating the value.
此令牌必须允许访问的网络将数据包定向到NAS以用于用户会话。在实践中，这一要求意味着访问的网络有两种实用的方法来创造价值。
The first method is to create an opaque token per NAS and then to store that information in a database. The database can be configured to allow querying by NAS IP address in order to find the correct Operator-NAS-Identifier. The database can also be configured to allow querying by Operator-NAS-Identifier in order to find the correct NAS IP address.
第一种方法是为每个NAS创建不透明令牌，然后将该信息存储在数据库中。数据库可以配置为允许通过NAS IP地址进行查询，以便找到正确的操作员NAS标识符。还可以将数据库配置为允许通过操作员NAS标识符进行查询，以找到正确的NAS IP地址。
The second method is to obfuscate the NAS IP address using information known locally by the visited network -- for example, by XORing it with a locally known secret key. The output of that obfuscation operation is data that can be used as the value of Operator-NAS-Identifier. On reception of a CoA packet, the locally known information can be used to unobfuscate the value of Operator-NAS-Identifier, in order to determine the actual NAS IP address.
第二种方法是使用访问的网络本地已知的信息混淆NAS IP地址，例如，使用本地已知的密钥对其进行XORing。该混淆操作的输出是可以用作操作员NAS标识符值的数据。在接收到CoA数据包时，本地已知信息可用于解模糊操作员NAS标识符的值，以确定实际NAS IP地址。
Note that there is no requirement that the value of Operator-NAS-Identifier be checked for integrity. Modification of the value can only result in the erroneous transaction being rejected.
请注意，不要求检查操作员NAS标识符的值的完整性。修改值只能导致错误交易被拒绝。
We note that the Access-Request and Accounting-Request packets often contain the Media Access Control (MAC) address of the NAS. There is therefore no requirement that Operator-NAS-Identifier obfuscate or hide in any way the total number of NASes in a visited network. That information is already public knowledge.
我们注意到，访问请求和记帐请求数据包通常包含NAS的媒体访问控制（MAC）地址。因此，不要求运营商NAS标识符以任何方式混淆或隐藏访问网络中的NASE总数。这些信息已经为公众所知。
The Operator-NAS-Identifier attribute MUST be stored by a home server along with any user session identification attributes. When sending a CoA packet for a user session, the home server MUST include verbatim any Operator-NAS-Identifier it has recorded for that session.
操作员NAS标识符属性必须与任何用户会话标识属性一起由家庭服务器存储。当为用户会话发送CoA数据包时，家庭服务器必须逐字包含它为该会话记录的任何运营商NAS标识符。
A home server MUST NOT send CoA packets for users of other networks. The next few sections describe how other participants in the RADIUS ecosystem can help enforce this requirement.
家庭服务器不得为其他网络的用户发送CoA数据包。接下来的几节将介绍RADIUS生态系统中的其他参与者如何帮助实施此要求。
A visited network that receives a CoA packet that will be proxied to a NAS MUST perform all of the operations required for proxies; see Section 4.3.2. We specify this requirement because we assume that the visited network has a proxy between the NAS and any external (i.e., third-party) proxy. Situations where a NAS sends packets directly to a third-party RADIUS server are outside the scope of this specification.
接收将被代理到NAS的CoA数据包的到访网络必须执行代理所需的所有操作；见第4.3.2节。我们之所以指定此要求，是因为我们假设访问的网络在NAS和任何外部（即第三方）代理之间有一个代理。NAS直接向第三方RADIUS服务器发送数据包的情况超出本规范的范围。
The visited network uses the contents of the Operator-NAS-Identifier attribute to determine which NAS will receive the packet.
访问的网络使用操作员NAS标识符属性的内容来确定哪个NAS将接收数据包。
The visited network MUST remove the Operator-Name and Operator-NAS-Identifier attributes from a given CoA packet prior to sending that packet to the final CoA server (i.e., NAS). This step is necessary due to the limits specified in Section 2.3 of [RFC5176].
在将给定的CoA数据包发送到最终的CoA服务器（即NAS）之前，访问的网络必须从该数据包中删除运营商名称和运营商NAS标识符属性。由于[RFC5176]第2.3节中规定的限制，此步骤是必要的。
The visited network MUST also ensure that the CoA packet sent to the NAS contains one of the following attributes: NAS-IP-Address, NAS-IPv6-Address, or NAS-Identifier. This step is the inverse of the removal suggested above in Section 3.4.
访问的网络还必须确保发送到NAS的CoA数据包包含以下属性之一：NAS IP地址、NAS-IPv6-Address或NAS标识符。该步骤与上文第3.4节中建议的移除相反。
In general, the NAS should only receive attributes that identify or modify a user's session. It is not appropriate to send to a NAS attributes that are used only for inter-proxy signaling.
通常，NAS应该只接收标识或修改用户会话的属性。向NAS发送仅用于代理间信令的属性是不合适的。
There are a number of requirements on both CoA proxies and RADIUS proxies. For the purpose of this section, we assume that each RADIUS proxy shares a common administration with a corresponding CoA proxy and that the two systems can communicate electronically. There is no requirement that these systems be co-located.
CoA代理和RADIUS代理都有许多要求。在本节中，我们假设每个RADIUS代理与相应的CoA代理共享一个公共管理，并且两个系统可以电子通信。不要求这些系统位于同一地点。
Section 6.1 of [RFC5176] has some security requirements on proxies that handle CoA-Request and Disconnect-Request packets:
[RFC5176]第6.1节对处理CoA请求和断开请求数据包的代理有一些安全要求：
... a proxy MAY perform a "reverse path forwarding" (RPF) check to verify that a Disconnect-Request or CoA-Request originates from an authorized Dynamic Authorization Client.
... 代理可以执行“反向路径转发”（RPF）检查，以验证断开连接请求或CoA请求是否源自授权的动态授权客户端。
We strengthen that requirement by saying that a proxy MUST perform a reverse path forwarding check to verify that a CoA packet originates from an authorized Dynamic Authorization Client. Without this check, a proxy may forward packets from misconfigured or malicious parties and thus contribute to the problem instead of preventing it. Where the check fails, the proxy MUST return a NAK packet that contains an Error-Cause Attribute having value 502 ("Request Not Routable").
我们强调了这一要求，即代理必须执行反向路径转发检查，以验证CoA数据包是否来自授权的动态授权客户端。如果不进行此检查，代理可能会转发来自配置错误或恶意方的数据包，从而导致问题的发生，而不是阻止问题的发生。如果检查失败，代理必须返回一个NAK数据包，该数据包包含一个值为502的错误原因属性（“请求不可路由”）。
Proxies that record user session information SHOULD verify the contents of a received CoA packet against the recorded data for that user session. If the proxy determines that the information in the packet does not match the recorded user session, it SHOULD return a NAK packet that contains an Error-Cause Attribute having value 503 ("Session Context Not Found"). These checks cannot be mandated due to the fact that [RFC5176] offers no advice on which attributes are used to identify a user's session.
记录用户会话信息的代理应根据该用户会话的记录数据验证接收到的CoA数据包的内容。如果代理确定数据包中的信息与记录的用户会话不匹配，则它应返回一个NAK数据包，该数据包包含一个值为503的错误原因属性（“未找到会话上下文”）。由于[RFC5176]没有提供关于哪些属性用于识别用户会话的建议，因此无法强制执行这些检查。
Because a RADIUS proxy will see Access-Request and Accounting-Request packets, we recognize that it will have sufficient information to forge CoA packets. The RADIUS proxy will thus have the ability to subsequently disconnect any user who was authenticated through itself.
因为RADIUS代理将看到访问请求和记帐请求数据包，所以我们认识到它将拥有足够的信息来伪造CoA数据包。因此，RADIUS代理将能够随后断开通过自身身份验证的任何用户的连接。
We suggest that the real-world effect of this security problem is minimal. RADIUS proxies can already return Access-Accept or Access-Reject for Access-Request packets and can change authorization attributes contained in an Access-Accept. Allowing a proxy to change (or disconnect) a user session post-authentication is not substantially different from changing (or refusing to connect) a user session during the initial process of authentication.
我们认为，这个安全问题对现实世界的影响是最小的。RADIUS代理已经可以为访问请求数据包返回访问接受或访问拒绝，并且可以更改访问接受中包含的授权属性。允许代理在身份验证后更改（或断开）用户会话与在初始身份验证过程中更改（或拒绝连接）用户会话没有本质区别。
The biggest problem is that there are no provisions in RADIUS for "end-to-end" security. That is, the visited network and home network cannot communicate privately in the presence of proxies. This limitation originates from the design of RADIUS for Access-Request and Accounting-Request packets. That limitation is then carried over to CoA-Request and Disconnect-Request packets.
最大的问题是RADIUS中没有关于“端到端”安全性的规定。也就是说，访问的网络和家庭网络不能在存在代理的情况下私下通信。这种限制源于访问请求和记帐请求数据包的RADIUS设计。然后将该限制转移到CoA请求和断开请求数据包。
We therefore cannot prevent proxies or home servers from forging CoA packets. We can only create scenarios where that forgery is hard to perform, is likely to be detected, and/or has no effect.
因此，我们无法阻止代理或家庭服务器伪造CoA数据包。我们只能创建伪造难以执行、可能被检测到和/或没有效果的场景。
Section 2.3 of [RFC5176] makes the following requirement for CoA servers:
[RFC5176]第2.3节对CoA服务器提出了以下要求：
In CoA-Request and Disconnect-Request packets, all attributes MUST be treated as mandatory.
在CoA请求和断开连接请求数据包中，所有属性都必须视为强制属性。
This requirement is too stringent for a CoA proxy. Only the final CoA server (i.e., NAS) can decide which attributes are mandatory and which are not.
这一要求对于CoA代理而言过于严格。只有最终的CoA服务器（即NAS）可以决定哪些属性是必需的，哪些不是。
Instead, in the case of a CoA proxy, we say that all attributes MUST NOT be treated as mandatory. Proxies implementing this specification MUST perform proxying based on Operator-Name. Other schemes are possible but are not discussed here. Proxies SHOULD forward all packets either "as is" or with minimal changes.
相反，在CoA代理的情况下，我们说所有属性都不能被视为强制性的。实现此规范的代理必须基于操作员名称执行代理。其他方案是可能的，但此处不讨论。代理应“按原样”转发所有数据包，或进行最小更改。
We note that some NAS implementations currently treat signaling attributes as mandatory. For example, some NAS implementations will NAK any CoA packet that contains a Proxy-State attribute. While this behavior is based on a straightforward reading of the above text, it causes problems in practice.
我们注意到，一些NAS实现目前将信令属性视为强制属性。例如，一些NAS实现将NAK任何包含代理状态属性的CoA数据包。虽然这种行为是基于对上述文本的直截了当的阅读，但它在实践中会导致问题。
We update Section 2.3 of [RFC5176] as follows: in CoA-Request and Disconnect-Request packets, the NAS MUST NOT treat as mandatory any attribute that is known to not affect the user's session -- for example, the Proxy-State attribute. Proxy-State is an attribute used for proxy-to-proxy signaling. It cannot affect the user's session, and therefore Proxy-State (and similar attributes) MUST be ignored by the NAS.
我们将[RFC5176]的第2.3节更新如下：在CoA请求和断开连接请求数据包中，NAS不得将已知不影响用户会话的任何属性（例如，代理状态属性）视为强制属性。代理状态是用于代理到代理信令的属性。它不会影响用户的会话，因此NAS必须忽略代理状态（和类似属性）。
When Operator-Name and/or Operator-NAS-Identifier are received by a proxy, the proxy MUST pass those attributes through unchanged. This requirement applies to all proxies, including proxies that forward any or all of Access-Request, Accounting-Request, CoA-Request, and Disconnect-Request packets.
当代理服务器接收到操作员名称和/或操作员NAS标识符时，代理服务器必须通过这些属性。此要求适用于所有代理，包括转发任何或所有访问请求、记帐请求、CoA请求和断开连接请求数据包的代理。
All attributes added by a RADIUS proxy when sending packets from the visited network to the home network MUST be removed by the corresponding CoA proxy from packets traversing the reverse path. That is, any editing of attributes that is done on the "forward" path MUST be undone on the "reverse" path.
当从到访网络向家庭网络发送数据包时，RADIUS代理添加的所有属性必须由相应的CoA代理从穿过反向路径的数据包中删除。也就是说，在“正向”路径上完成的任何属性编辑都必须在“反向”路径上撤消。
The result is that a NAS will only ever receive CoA packets that either contain (1) attributes sent by the NAS to its local RADIUS server or (2) attributes that are sent by the home server in order to perform a change of authorization.
结果是NAS将只接收包含（1）NAS发送到其本地RADIUS服务器的属性或（2）家庭服务器为执行授权更改而发送的属性的CoA数据包。
Finally, we extend the above requirement not only to Operator-Name and Operator-NAS-Identifier but also to any future attributes that are added for proxy-to-proxy signaling.
最后，我们不仅将上述要求扩展到运营商名称和运营商NAS标识符，还扩展到为代理到代理信令添加的任何未来属性。
This section describes how the two attributes work together to permit CoA proxying.
本节介绍这两个属性如何协同工作以允许CoA代理。
In this scenario, we follow a roaming user who is attempting to log in to a visited network. The login attempt is done via a NAS in the visited network. That NAS will send an Access-Request packet to the visited RADIUS server. The visited RADIUS server will see that the user is roaming and will add an Operator-Name attribute, with value "1" followed by its own realm name, e.g., "1example.com". The visited RADIUS server MAY also add an Operator-NAS-Identifier attribute. The NAS identification attributes are also edited, as required by Section 3.4, above.
在这个场景中，我们跟踪一个漫游用户，他正试图登录到一个已访问的网络。登录尝试通过访问网络中的NAS完成。NAS将向访问的RADIUS服务器发送访问请求数据包。访问的RADIUS服务器将看到用户正在漫游，并将添加一个操作员名称属性，值为“1”，后跟其自己的域名，例如“1example.com”。访问的RADIUS服务器还可以添加操作员NAS标识符属性。根据上述第3.4节的要求，还可以编辑NAS标识属性。
The visited server will then proxy the authentication request to an upstream server. That server may be the home server, or it may be a proxy. In the case of a proxy, the proxy will forward the packet until the packet reaches the home server.
然后，访问的服务器将把身份验证请求代理给上游服务器。该服务器可能是家庭服务器，也可能是代理服务器。对于代理，代理将转发数据包，直到数据包到达家庭服务器。
The home server will record the Operator-Name and Operator-NAS-Identifier attributes, along with other information about the user's session, if those attributes are present in a packet.
家庭服务器将记录运营商名称和运营商NAS标识符属性，以及有关用户会话的其他信息（如果这些属性存在于数据包中）。
At some later point in time, the home server determines that (1) a user session should have its authorization changed or (2) the user should be disconnected. The home server looks up the Operator-Name and Operator-NAS-Identifier attributes, along with other user session identifiers as described in [RFC5176]. The home server then looks up the realm from the Operator-Name attribute in the logical AAA routing table, in order to find the next-hop CoA server for that realm (which may be a proxy). The CoA-Request is then sent to that CoA server.
在稍后的某个时间点，家庭服务器确定（1）用户会话应更改其授权或（2）用户应断开连接。家庭服务器查找操作员名称和操作员NAS标识符属性，以及[RFC5176]中所述的其他用户会话标识符。然后，家庭服务器从逻辑AAA路由表中的Operator Name属性中查找域，以便找到该域的下一个跃点CoA服务器（可能是代理）。然后将CoA请求发送到该CoA服务器。
The CoA server receives the request and, if it is a proxy, performs a lookup similar to the lookup done by the home server. The packet is then proxied repeatedly until it reaches the visited network.
CoA服务器接收请求，如果是代理，则执行类似于家庭服务器执行的查找的查找。然后重复代理数据包，直到它到达访问的网络。
If the proxy cannot find a destination for the request or if no Operator-Name attribute exists in the request, the proxy will return a CoA-NAK with Error-Cause 502 ("Request Not Routable").
如果代理找不到请求的目的地，或者请求中不存在操作员名称属性，则代理将返回一个CoA NAK，错误原因为502（“请求不可路由”）。
The visited network will receive the CoA-Request packet and will use the Operator-NAS-Identifier attribute (if available) to determine which local CoA server (i.e., NAS) the packet should be sent to. If there is no Operator-NAS-Identifier attribute, the visited network may use other means to locate the NAS, such as consulting a local database that tracks user sessions.
访问的网络将接收CoA请求数据包，并将使用操作员NAS标识符属性（如果可用）来确定数据包应发送到哪个本地CoA服务器（即NAS）。如果没有操作员NAS标识符属性，则访问的网络可以使用其他方法来定位NAS，例如咨询跟踪用户会话的本地数据库。
The Operator-Name and Operator-NAS-Identifier attributes are then removed from the packet; one of NAS-IP-Address, NAS-IPv6-Address, or NAS-Identifier is added to the packet; and the packet is then sent to the CoA server.
然后从数据包中删除操作员名称和操作员NAS标识符属性；向数据包添加NAS IP地址、NAS-IPv6-Address或NAS标识符中的一个；然后，数据包被发送到CoA服务器。
If no CoA server can be found, the visited network returns a CoA-NAK with Error-Cause 403 ("NAS Identification Mismatch").
如果找不到CoA服务器，访问的网络返回一个CoA NAK，错误原因为403（“NAS标识不匹配”）。
Any response from the CoA server (NAS) is returned to the home network via the normal method of returning responses to requests.
来自CoA服务器（NAS）的任何响应都通过返回请求响应的正常方法返回到家庭网络。
This specification incorporates by reference Section 11 of [RFC6929]. In short, RADIUS has many known issues; those issues are discussed in detail in [RFC6929] and do not need to be repeated here.
本规范通过引用纳入[RFC6929]第11节。简而言之，RADIUS存在许多已知问题；[RFC6929]中详细讨论了这些问题，无需在此重复。
This specification adds one new attribute and defines new behavior for RADIUS proxying. As this behavior mirrors existing RADIUS proxying, we do not believe that it introduces any new security issues. We note, however, that RADIUS proxying has many inherent security issues.
此规范添加了一个新属性，并定义了半径代理的新行为。由于此行为反映了现有的RADIUS代理，我们认为它不会带来任何新的安全问题。然而，我们注意到，RADIUS代理存在许多固有的安全问题。
The requirement that packets be signed with a shared secret means that a CoA packet can only be received from a trusted party or, transitively, received from a third party via a trusted party. This security provision of the base RADIUS protocol makes it impossible for untrusted parties to affect the user's session.
使用共享秘密对数据包进行签名的要求意味着CoA数据包只能从受信任方接收，或者通过受信任方从第三方接收。基本RADIUS协议的这种安全规定使得不受信任的各方不可能影响用户的会话。
When RADIUS proxying is performed, all packets are signed on a hop-by-hop basis. Any intermediate proxy can therefore forge packets, replay packets, or modify the contents of any packet. Any system receiving correctly signed packets must accept them at face value and is unable to detect any forgery, replay, or modifications. As a result, the secure operation of such a system depends largely on trust instead of on technical means.
当执行RADIUS代理时，所有数据包都会逐跳签名。因此，任何中间代理都可以伪造数据包、重播数据包或修改任何数据包的内容。任何接收到正确签名的数据包的系统都必须按面值接受这些数据包，并且无法检测任何伪造、重播或修改。因此，这种系统的安全运行在很大程度上取决于信任，而不是技术手段。
CoA packet proxying has all of the same issues as those noted above. We note that the proxies that see and can modify CoA packets are generally the same proxies that can see or modify Access-Request and Accounting-Request packets. As such, there are few additional security implications in allowing CoA proxying.
CoA数据包代理具有与上述问题相同的所有问题。我们注意到，查看和修改CoA数据包的代理通常与查看或修改访问请求和记帐请求数据包的代理相同。因此，允许CoA代理几乎没有额外的安全影响。
The main security implication that remains is that home networks now have the ability to disconnect or change the authorization of users in a visited network. As this capability is only enabled when mutual agreement is in place, and only for those parties who can already control user sessions, there are no new security issues with this specification.
仍然存在的主要安全含义是，家庭网络现在能够断开或更改访问网络中用户的授权。由于此功能仅在双方达成协议时启用，并且仅适用于那些已经可以控制用户会话的各方，因此此规范没有新的安全问题。
Nothing in this specification depends on the security of the Operator-NAS-Identifier attribute. The entire process would work exactly the same if the Operator-NAS-Identifier attribute simply contained the NAS IP address that is hosting the user's session. The only real downside in that situation would be that external parties would see some additional private information about the visited network. They would still, however, be unable to leverage that information to do anything malicious.
本规范中的任何内容都不取决于操作员NAS标识符属性的安全性。如果Operator NAS Identifier属性仅包含承载用户会话的NAS IP地址，则整个过程将完全相同。在这种情况下，唯一真正的缺点是外部各方会看到有关访问网络的一些额外的私人信息。然而，他们仍然无法利用这些信息做任何恶意的事情。
The main reason to use an opaque token for the Operator-NAS-Identifier attribute is that there is no compelling reason to make the information public. We therefore recommend that the value be simply an opaque token. We also state that there is no requirement for integrity protection or replay detection of this attribute. The rest of the RADIUS protocol ensures that modification or replay of the Operator-NAS-Identifier attribute will either have no effect or have the same effect as if the value had not been modified.
对操作员NAS标识符属性使用不透明令牌的主要原因是，没有令人信服的理由公开信息。因此，我们建议该值只是一个不透明的标记。我们还声明，不需要对该属性进行完整性保护或重播检测。RADIUS协议的其余部分可确保对操作员NAS标识符属性的修改或重播不会产生任何效果，或与未修改该值时产生相同的效果。
Trusted parties can modify a user's session on the NAS only when they have sufficient information to identify that session. In practice, this limitation means that those parties already have access to the user's session information. In other words, those parties are the proxies who are already forwarding Access-Request and Accounting-Request packets.
受信任方只有在拥有足够的信息来标识用户在NAS上的会话时，才能修改该会话。实际上，这一限制意味着这些参与方已经可以访问用户的会话信息。换句话说，这些方是已经在转发访问请求和记帐请求数据包的代理。
Since those parties already have the ability to see and modify all of the information about a user's session, there is no additional security issue with allowing them to see and modify CoA packets.
由于这些参与方已经能够查看和修改有关用户会话的所有信息，因此允许他们查看和修改CoA数据包不存在额外的安全问题。
In short, any security issues with the contents of Operator-NAS-Identifier are largely limited by the security of the underlying RADIUS protocol. This limitation means that it does not matter how the values of Operator-NAS-Identifier are created, stored, or used.
简而言之，运营商NAS标识符内容的任何安全问题在很大程度上都受到基础RADIUS协议安全性的限制。这一限制意味着，如何创建、存储或使用操作员NAS标识符的值并不重要。
Per Section 3.4 of this document, IANA has allocated one new RADIUS attribute (the Operator-NAS-Identifier attribute) from the "short extended space" of the "RADIUS Attribute Types" registry as follows:
根据本文件第3.4节，IANA从“RADIUS属性类型”注册表的“短扩展空间”中分配了一个新的RADIUS属性（操作员NAS标识符属性），如下所示：
Value: 241.8 Description: Operator-NAS-Identifier Data Type: string Reference: RFC 8559
值：241.8说明：操作员NAS标识符数据类型：字符串参考：RFC 8559
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://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, <https://www.rfc-editor.org/info/rfc2865>.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 2865，DOI 10.17487/RFC2865，2000年6月<https://www.rfc-editor.org/info/rfc2865>.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, DOI 10.17487/RFC5080, December 2007, <https://www.rfc-editor.org/info/rfc5080>.
[RFC5080]Nelson，D.和A.DeKok，“通用远程身份验证拨入用户服务（RADIUS）实施问题和建议修复”，RFC 5080，DOI 10.17487/RFC5080，2007年12月<https://www.rfc-editor.org/info/rfc5080>.
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, DOI 10.17487/RFC5176, January 2008, <https://www.rfc-editor.org/info/rfc5176>.
[RFC5176]Chiba，M.，Dommety，G.，Eklund，M.，Mitton，D.，和B.Aboba，“远程认证拨号用户服务（RADIUS）的动态授权扩展”，RFC 5176，DOI 10.17487/RFC5176，2008年1月<https://www.rfc-editor.org/info/rfc5176>.
[RFC5580] Tschofenig, H., Ed., Adrangi, F., Jones, M., Lior, A., and B. Aboba, "Carrying Location Objects in RADIUS and Diameter", RFC 5580, DOI 10.17487/RFC5580, August 2009, <https://www.rfc-editor.org/info/rfc5580>.
[RFC5580]Tschofenig，H.，Ed.，Adrangi，F.，Jones，M.，Lior，A.，和B.Aboba，“以半径和直径携带定位物体”，RFC 5580，DOI 10.17487/RFC5580，2009年8月<https://www.rfc-editor.org/info/rfc5580>.
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, DOI 10.17487/RFC6929, April 2013, <https://www.rfc-editor.org/info/rfc6929>.
[RFC6929]DeKok，A.和A.Lior，“远程身份验证拨入用户服务（RADIUS）协议扩展”，RFC 6929，DOI 10.17487/RFC6929，2013年4月<https://www.rfc-editor.org/info/rfc6929>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015, <https://www.rfc-editor.org/info/rfc7542>.
[RFC7542]DeKok，A.，“网络访问标识符”，RFC 7542，DOI 10.17487/RFC7542，2015年5月<https://www.rfc-editor.org/info/rfc7542>.
[RFC8044] DeKok, A., "Data Types in RADIUS", RFC 8044, DOI 10.17487/RFC8044, January 2017, <https://www.rfc-editor.org/info/rfc8044>.
[RFC8044]DeKok，A.，“半径中的数据类型”，RFC 8044，DOI 10.17487/RFC8044，2017年1月<https://www.rfc-editor.org/info/rfc8044>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, DOI 10.17487/RFC2866, June 2000, <https://www.rfc-editor.org/info/rfc2866>.
[RFC2866]Rigney，C.，“半径会计”，RFC 2866，DOI 10.17487/RFC2866，2000年6月<https://www.rfc-editor.org/info/rfc2866>.
Authors' Addresses
作者地址
Alan DeKok The FreeRADIUS Server Project
Alan DeKok FreeRADIUS服务器项目
Email: aland@freeradius.org
Email: aland@freeradius.org
Jouni Korhonen
朱尼·科霍宁
Email: jouni.nospam@gmail.com
Email: jouni.nospam@gmail.com