Internet Engineering Task Force (IETF) P. Duffy
Request for Comments: 6345 Cisco
Category: Standards Track S. Chakrabarti
ISSN: 2070-1721 Ericsson
R. Cragie
PG&E
Y. Ohba, Ed.
Toshiba
A. Yegin
Samsung
August 2011
Internet Engineering Task Force (IETF) P. Duffy
Request for Comments: 6345 Cisco
Category: Standards Track S. Chakrabarti
ISSN: 2070-1721 Ericsson
R. Cragie
PG&E
Y. Ohba, Ed.
Toshiba
A. Yegin
Samsung
August 2011
Protocol for Carrying Authentication for Network Access (PANA) Relay Element
承载网络访问认证（PANA）中继元件的协议
Abstract
摘要
This document specifies Protocol for carrying Authentication for Network Access (PANA) Relay Element functionality, which enables PANA messaging between a PANA Client (PaC) and a PANA Authentication Agent (PAA) where the two nodes cannot reach each other by means of regular IP routing.
本文件规定了用于承载网络访问认证（PANA）中继元件功能的协议，该协议支持PANA客户端（PaC）和PANA认证代理（PAA）之间的PANA消息传递，其中两个节点无法通过常规IP路由相互联系。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6345.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6345.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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 ....................................................2
1.1. Specification of Requirements ..............................3
2. PANA Relay Element ..............................................3
3. Security of Messages Sent between PRE and PAA ...................5
4. PANA Messages for Relay Operation ...............................7
4.1. PANA-Relay .................................................7
5. PANA AVPs for Relay Operation ...................................7
5.1. PaC-Information AVP ........................................7
5.2. Relayed-Message AVP ........................................7
6. Security Considerations .........................................8
7. IANA Considerations ............................................10
8. Acknowledgments ................................................10
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................11
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................3
2. PANA Relay Element ..............................................3
3. Security of Messages Sent between PRE and PAA ...................5
4. PANA Messages for Relay Operation ...............................7
4.1. PANA-Relay .................................................7
5. PANA AVPs for Relay Operation ...................................7
5.1. PaC-Information AVP ........................................7
5.2. Relayed-Message AVP ........................................7
6. Security Considerations .........................................8
7. IANA Considerations ............................................10
8. Acknowledgments ................................................10
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................11
Protocol for carrying Authentication for Network Access (PANA) [RFC5191] is a UDP-based protocol to perform Extensible Authentication Protocol (EAP) authentication between a PANA Client (PaC) and a PANA Authentication Agent (PAA).
用于承载网络访问身份验证（PANA）的协议[RFC5191]是基于UDP的协议，用于在PANA客户端（PaC）和PANA身份验证代理（PAA）之间执行可扩展身份验证协议（EAP）身份验证。
This document specifies PANA Relay Element (PRE) functionality, which enables PANA messaging between a PaC and a PAA where the two nodes cannot reach each other by means of regular IP routing. For example, in ZigBee IP [ZIGBEEIP] that uses 6LoWPAN [RFC4944], a joining node (PaC) can only use a link-local IPv6 address to communicate with a parent node prior to PANA authentication. The PAA typically resides in a 6LowPAN Border Router (6LBR) [6LoWPAN-ND], which is often
本文档规定了PANA中继元素（PRE）功能，该功能支持PaC和PAA之间的PANA消息传递，其中两个节点无法通过常规IP路由相互联系。例如，在使用6LoWPAN[RFC4944]的ZigBee IP[ZIGBEEIP]中，加入节点（PaC）只能在PANA身份验证之前使用链路本地IPv6地址与父节点通信。PAA通常驻留在6LowPAN边界路由器（6LBR）[6LowPAN ND]中，通常
multiple IP hops away from the PaC. The PRE implemented on the parent node is used for relaying PANA messages between the PaC and the PAA in this scenario.
多个IP跳离PaC。在此场景中，在父节点上预实现的用于在PaC和PAA之间中继PANA消息。
In this document, several words are used to signify the requirements of the specification. These words are capitalized. 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]中所述进行解释。
A PANA Relay Element (PRE) is a node that is located between a PaC and a PAA. It is responsible for relaying the PANA messages between the PaC and the PAA. The PRE does not need to maintain per-PaC state. From the PaC's perspective, the PRE appears as the PAA. Normal IP routing is performed between the PRE and the PAA. A PAA can communicate with multiple PREs. A PRE can communicate with multiple PAAs, and it will choose one PAA to communicate with for a given PaC. By default, the PaC discovers the PRE using the normal mechanism for PAA discovery as defined in [RFC5192]. PREs are assumed to be configured with the IP address(es) of the PAA(s). Dynamic PAA discovery schemes for PREs are outside the scope of this document.
PANA中继元件（PRE）是位于PaC和PAA之间的节点。它负责在PaC和PAA之间传递PANA消息。PRE不需要维护每个PaC状态。从PaC的角度来看，PRE显示为PAA。在PRE和PAA之间执行正常的IP路由。一个PAA可以与多个PRE通信。一个PRE可以与多个PAA通信，并且它将为给定的PaC选择一个PAA进行通信。默认情况下，PaC使用[RFC5192]中定义的PAA发现的正常机制来发现预处理。假定PRE配置有PAA的IP地址。PREs的动态PAA发现方案不在本文档范围内。
The PRE and the PAA support the relay operation as follows.
PRE和PAA支持如下继电器操作。
When the PRE receives a PANA message from the PaC, it creates a PANA-Relay (PRY) message (see Section 4.1) containing a Relayed-Message AVP (see Section 5.2) and a PaC-Information AVP (see Section 5.1). The Relayed-Message AVP encapsulates the entire PANA Message received from the PaC. The PaC-Information AVP contains the PaC's IP address and UDP port number used for sending the PANA messages. The PRY message is sent to the PAA.
当PRE从PaC接收到PANA消息时，它会创建一条PANA中继（PRY）消息（见第4.1节），其中包含中继消息AVP（见第5.2节）和PaC信息AVP（见第5.1节）。中继消息AVP封装了从PaC接收的整个PANA消息。PaC信息AVP包含PaC的IP地址和用于发送PANA消息的UDP端口号。PRY消息被发送到PAA。
When the PAA receives the PRY message, it retrieves the PaC-originated PANA message from the Relayed-Message AVP and the PaC's IP address and UDP port number from the PaC-Information AVP. The PaC-originated PANA message is processed in the same way as specified in [RFC5191], with the following exceptions:
当PAA接收到PRY消息时，它从中继消息AVP检索PaC原始PANA消息，并从PaC信息AVP检索PaC的IP地址和UDP端口号。以[RFC5191]中规定的相同方式处理源自PaC的PANA消息，但以下情况除外：
(a) The IP address and the port number contained in the PaC-Information AVP and the source IP address and UDP port number of the PRE are used to identify the PaC among multiple PANA-Client-Initiation messages sent from different PaCs through the same PRE
(a) PaC信息AVP中包含的IP地址和端口号以及PRE的源IP地址和UDP端口号用于在通过同一PRE从不同PaC发送的多个PANA客户端启动消息中识别PaC
or sent from more than one PaC with the same the IP address and the port number through different PREs.
或者从多个具有相同IP地址和端口号的PaC通过不同的PRE发送。
(b) The IP address and the port number contained in the PaC-Information AVP are maintained by the PAA in the PANA session attribute "IP address and UDP port number of the PaC" [RFC5191].
(b) PAA在PANA会话属性“PaC的IP地址和UDP端口号”中维护PaC信息AVP中包含的IP地址和端口号[RFC5191]。
(c) The IP address and UDP port number of the PRE are maintained by the PAA in a new PANA session attribute "IP address and UDP port number of the PRE". A PANA session is referred to as a relayed PANA session if this attribute has a non-null value.
(c) PAA在新的PANA会话属性“PRE的IP地址和UDP端口号”中维护PRE的IP地址和UDP端口号。如果此属性具有非空值，则PANA会话称为中继PANA会话。
When the PAA originates a PANA message for a relayed PANA session, it sends a PRY message to the PRE's IP address and sets the destination UDP port number to the UDP port number of the PRE maintained in the PANA session attribute "IP address and UDP port number of the PRE". The PRY message includes a Relayed-Message AVP containing the PAA-originated PANA message and also includes a PaC-Information AVP containing the PaC's IP address and UDP port number.
当PAA为中继PANA会话发出PANA消息时，它向PRE的IP地址发送PRY消息，并将目标UDP端口号设置为PANA会话属性“PRE的IP地址和UDP端口号”中维护的PRE的UDP端口号。PRY消息包括包含源自PAA的PANA消息的中继消息AVP，还包括包含PaC的IP地址和UDP端口号的PaC信息AVP。
When the PRE receives the PRY message, it retrieves the PAA-originated PANA message from the Relayed-Message AVP and the PaC's IP address and UDP port number from and PaC-Information AVPs. The PAA-originated PANA message is sent to the PaC's IP address with the source UDP port number set to the PANA port number (716) and the destination UDP port number set to the UDP port number contained in the Relayed-Message AVP.
当PRE接收到PRY消息时，它从中继消息AVP和PaC的IP地址和UDP端口号以及PaC信息AVP中检索源自PAA的PANA消息。源自PAA的PANA消息被发送到PaC的IP地址，源UDP端口号设置为PANA端口号（716），目标UDP端口号设置为中继消息AVP中包含的UDP端口号。
The Session Identifier and Sequence Number of any PRY message are set to zero. PRY messages are never retransmitted by the PRE or the PAA. Note that the PANA message carried in a Relayed-Message AVP may be retransmitted by the PaC or PAA, leading to transmission of a new PRY message carrying the same Relayed-Message AVP.
任何PRY消息的会话标识符和序列号都设置为零。PRE或PAA从不重新传输PRY消息。注意，中继消息AVP中携带的PANA消息可由PaC或PAA重新传输，从而导致携带相同中继消息AVP的新PRY消息的传输。
A PAA that supports this specification MUST be able to process PRY messages for PaC-initiated PANA sessions.
支持此规范的PAA必须能够处理PaC启动的PANA会话的PRY消息。
This specification assumes there is at most one PRE between the PaC and the PAA. Performing relay operation on a PANA message that is already relayed (i.e., carried inside a PRY message) is out of scope of this specification.
本规范假设PaC和PAA之间最多有一个PRE。对已经中继的PANA报文（即，在PRY报文内进行的报文）执行中继操作超出本规范的范围。
Figure 1 is an example message flow with a PRE.
图1是一个带有预处理的消息流示例。
PaC PRE PAA srcIP:port->dstIP:port
----- ----- ----- ----------------------
1. ---PCI--> IP1:p1 -> IP2a:716
PaC PRE PAA srcIP:port->dstIP:port
----- ----- ----- ----------------------
1. ---PCI--> IP1:p1 -> IP2a:716
IP1 is the IP address of PaC.
IP1是PaC的IP地址。
IP2a and IP2b are the IP addresses of PRE. IP2a is used for communicating with PaC. IP2b is used for communicating with PAA. The two IP address may be the same.
IP2a和IP2b是PRE的IP地址。IP2a用于与PaC通信。IP2b用于与PAA通信。这两个IP地址可能相同。
IP3 is the IP address of PAA.
IP3是PAA的IP地址。
p1 is PaC-assigned UDP port number. p2 is PRE-assigned UDP port number.
p1是PaC分配的UDP端口号。p2是预先分配的UDP端口号。
P: PaC-Information AVP R: Relayed-Message AVP
P:PaC信息AVP R：中继消息AVP
Figure 1: Example Call Message for PANA Relay
图1:PANA中继的呼叫消息示例
PRE/PAA security is OPTIONAL since PANA messages are designed to be used in untrusted networks, but if a cryptographic mechanism is supported, it SHOULD be IPsec. When the device characteristics preclude support for IPsec, an alternative mechanism such as DTLS [RFC4347], or link-layer cryptographic security, etc., may be used instead. This section describes how IPsec [RFC4301] can be used for securing the PANA relay messages.
PRE/PAA安全性是可选的，因为PANA消息设计用于不受信任的网络，但如果支持加密机制，则应为IPsec。当设备特性排除对IPsec的支持时，可以使用替代机制，例如DTLS[RFC4347]或链路层加密安全性等。本节介绍如何使用IPsec[RFC4301]保护PANA中继消息。
When IPsec is used, each PRE must have an established pairwise trust relationship with a PAA. That is, if messages from a PaC will be relayed by a PRE to a PAA, the PRE and PAA must be configured to use IPsec for the messages they exchange.
使用IPsec时，每个PRE必须与PAA建立成对信任关系。也就是说，如果来自PaC的消息将由PRE中继到PAA，则必须将PRE和PAA配置为对其交换的消息使用IPsec。
PREs and PAAs that support secure PRE to PAA communication use IPsec under the following conditions:
支持安全预到PAA通信的PREs和PAA在以下条件下使用IPsec：
Selectors PREs are manually configured with the addresses of the PAAs to which PANA messages are to be forwarded. PAAs that will be using IPsec for securing PANA messages must also be configured with a list of the PREs to which messages will be returned. The selectors for the PREs and PAAs will be the pairs of addresses defining PREs and PAAs that exchange PANA messages on the PANA UDP port 716 in their source or destination port.
选择器PREs手动配置PANA消息转发到的PAA地址。将使用IPsec保护PANA消息的PAAs还必须配置消息将返回到的PRE列表。PREs和PAAs的选择器将是定义PREs和PAAs的地址对，它们在源端口或目标端口的PANA UDP端口716上交换PANA消息。
Mode PREs and PAAs use transport mode and ESP. The information in PANA messages is not generally considered confidential, so encryption need not be used (i.e., NULL encryption can be used).
模式PREs和PAAs使用传输模式，尤其是PANA消息中的信息通常不被视为机密信息，因此无需使用加密（即可以使用空加密）。
Key management Because the PREs and PAA must be manually configured, manually configured key management may suffice, but does not provide defense against replayed messages. Accordingly, IKE with preshared secrets SHOULD be supported. IKE with public keys MAY be supported.
密钥管理由于必须手动配置PREs和PAA，因此手动配置的密钥管理可能就足够了，但不能防止重播消息。因此，应该支持具有预共享秘密的IKE。可能支持带有公钥的IKE。
Security policy PANA messages between PREs and PAAs should only be accepted from PANA peers as identified in the local configuration.
PREs和PAAs之间的安全策略PANA消息只能从本地配置中标识的PANA对等方接受。
Authentication Shared keys, indexed to the source IP address of the received PANA message, are adequate in this application.
根据接收到的PANA消息的源IP地址编制索引的身份验证共享密钥在此应用程序中已足够。
Availability Appropriate IPsec implementations are likely to be available for PAAs and for PREs in more featureful devices used in enterprise and core ISP networks. IPsec is less likely to be available for PREs in low-end devices primarily used in the home or small office markets.
在企业和核心ISP网络中使用的功能更强大的设备中，PAAs和PREs可能会有合适的IPsec实现。IPsec不太可能用于主要用于家庭或小型办公室市场的低端设备中的PRE。
The PANA-Relay (PRY) message is sent by the PRE to the PAA or by the PAA to the PRE. It contains one PaC-Information AVP and one Relayed-Message AVP. The PRY message SHOULD NOT carry other AVPs.
PANA中继（PRY）信息由PRE发送至PAA，或由PAA发送至PRE。它包含一个PaC信息AVP和一个中继消息AVP。PRY信息不应携带其他AVP。
In a PRE-originated PRY message, the PaC-Information AVP contains an IP address and the UDP port number of the PANA message that was originated by the PaC and is contained in the Relayed-Message AVP.
在预先发起的PRY消息中，PaC信息AVP包含由PaC发起并包含在中继消息AVP中的PANA消息的IP地址和UDP端口号。
In a PAA-originated PRY message, the information in the PaC-Information AVP MUST be copied from the "IP address and UDP port number of the PaC" attribute of the associated PANA session [RFC5191].
在源自PAA的PRY消息中，PaC信息AVP中的信息必须从相关PANA会话[RFC5191]的“PaC的IP地址和UDP端口号”属性中复制。
The Session Identifier and Sequence Number field of any PRY message MUST be set to zero. A PRY message MUST NOT be retransmitted by the PRE or the PAA.
任何PRY消息的会话标识符和序列号字段必须设置为零。PRE或PAA不得重新传输PRY消息。
PANA-Relay ::= < PANA-Header: 5 >
{ PaC-Information }
{ Relayed-Message }
*[ AVP ]
PANA-Relay ::= < PANA-Header: 5 >
{ PaC-Information }
{ Relayed-Message }
*[ AVP ]
The PaC-Information AVP (AVP Code 10) is of type OctetString and contains an IP address (16-octet for an IPv6 address or 4-octet for an IPv4 address) followed by a 2-octet UDP port number of the PaC, both encoded in network-byte order.
PaC信息AVP（AVP代码10）为OctetString类型，包含一个IP地址（IPv6地址为16个八位组，IPv4地址为4个八位组），后跟PaC的2个八位组UDP端口号，均按网络字节顺序编码。
The Relayed-Message (AVP Code 11) is of type OctetString and contains a relayed PANA message excluding the UDP and IP headers.
中继消息（AVP代码11）为OctetString类型，包含不包括UDP和IP头的中继PANA消息。
A PRE's main objective is to assist transport of PANA messages between the PaC and the PAA. Relay operation performed between the PRE and the PAA forms an additional logical link for relaying the end-to-end PANA messages between the PaC and the PAA. In that sense, a PRE resembles a bridge or a router that sits between the PaC and the PAA when non-relayed PANA [RFC5191] is used.
PRE的主要目标是协助PaC和PAA之间的PANA信息传输。在PRE和PAA之间执行的中继操作形成用于在PaC和PAA之间中继端到端PANA消息的附加逻辑链路。从这个意义上讲，当使用非中继PANA[RFC5191]时，PRE类似于PaC和PAA之间的网桥或路由器。
A PRE can pose certain threats to the relayed PANA messages. A PRE can delay or drop PANA messages sent by the PaC or the PAA. It can also spoof or modify PANA messages sent towards the PaC or the PAA. These threats are similar to what an on-path bridge/router (i.e., a man-in-the-middle, MitM) can pose to non-relayed PANA. EAP and PANA protocols are designed to operate over unsecure links where aforementioned threats can already exist. Even though these threats cannot be leveraged to gain unauthorized network access, or compromise of cryptographic keys (e.g., MK, MSK, EMSK, etc.), other damages such as preventing authentication to complete, or denial-of service are still possible.
PRE可能对转发的PANA消息造成某些威胁。PRE可以延迟或丢弃PaC或PAA发送的PANA消息。它还可以欺骗或修改发送到PaC或PAA的PANA消息。这些威胁类似于路径网桥/路由器（即中间人，MitM）对非中继PANA造成的威胁。EAP和PANA协议设计用于在可能存在上述威胁的不安全链路上运行。即使不能利用这些威胁获得未经授权的网络访问，或泄露加密密钥（例如，MK、MSK、EMSK等），仍有可能造成其他损害，如阻止身份验证完成或拒绝服务。
Even though the PRE-to-PAA relay path appears to be a separate additional logical link for transporting the PANA messages, the PRE may pose a few additional risks versus traditional on-path bridges and routers. The following explains the risks and mitigations of PRE as a relay device.
尽管PRE-to-PAA中继路径似乎是用于传输PANA消息的单独的附加逻辑链路，但与传统的路径网桥和路由器相比，PRE可能会带来一些附加风险。以下解释了PRE作为中继设备的风险和缓解措施。
The PRE inserts PaC-Information AVP as the PaC-generated PANA packet is encapsulated in a PRY packet to the PAA. This AVP carries the IP address and the UDP port number values of the PANA packet as sent by the PAC. These values are already carried inside the IP and UDP headers with non-relayed PANA and they are not necessarily secured. EAP and PANA are designed to work in the absence of their protection. Therefore, no additional PANA-layer security is needed when these values are carried as PANA AVPs between the PRE and the PAA. If a future document defines additional payload AVPs for the PRY messages, there may be a need to define additional security for those messages.
当PaC生成的PANA数据包封装在PRY数据包中时，预插入PaC信息AVP到PAA。此AVP携带PAC发送的PANA数据包的IP地址和UDP端口号值。这些值已经通过非中继PANA在IP和UDP报头中携带，并且它们不一定是安全的。EAP和PANA设计用于在没有保护的情况下工作。因此，当这些值作为PANA AVP在PRE和PAA之间传输时，不需要额外的PANA层安全性。如果将来的文档为PRY消息定义了额外的有效负载AVP，则可能需要为这些消息定义额外的安全性。
A rogue PRE can spoof PANA messages on behalf of a victim PaC and receive the PAA response irrespective of the location of the PRE with respect to the network topology. Achieving the same threat with non-relayed PANA requires the rogue node be an MitM, otherwise the spoofed packets may be dropped by the ingress filtering network elements, or the responses would be directly sent to the victim PaC IP address and may not be received by the rogue node. Nevertheless, such a rogue PRE cannot perform full initial authentication on behalf of the victim PaC unless it also holds the PaC's credentials
流氓PRE可以代表受害者PaC欺骗PANA消息，并接收PAA响应，而不考虑PRE相对于网络拓扑的位置。使用非中继PANA实现相同的威胁要求流氓节点是MitM，否则，入侵过滤网络元件可能会丢弃伪造的数据包，或者响应将直接发送到受害者PaC IP地址，流氓节点可能不会收到。然而，这样的流氓PRE不能代表受害者PaC执行完整的初始身份验证，除非它还持有PaC的凭据
(including the master key). Furthermore, any spoofed PANA messages after the initial authentication will fail the integrity checks at the PAA when a key-generating EAP method is used.
（包括主钥匙）。此外，当使用密钥生成EAP方法时，初始身份验证后的任何伪造PANA消息都将无法通过PAA的完整性检查。
The only state that can change on the PAA upon a rogue PRE sending a spoofed PRY is the IP address and UDP port number of the PRE stored as PANA session attributes, which impacts where the PAA sends the next PANA packet (i.e., to the rogue PRE instead of the legitimate PRE). The PAA also needs to handle the PaC-Information AVP in addition to the PaC-originated PANA message carried in the Relayed-Message AVP, so use of the PRE may impose additional storage requirements on the PAA. A rogue PRE generating a valid PANA packet requires it be a MitM in order to synch up with the PANA session state and attributes on the PaC. Such a MitM can already disturb the EAP and PANA even without playing the role of a PRE.
在rogue PRE发送欺骗PRY时，PAA上唯一可以更改的状态是作为PANA会话属性存储的PRE的IP地址和UDP端口号，这会影响PAA发送下一个PANA数据包的位置（即，发送到rogue PRE而不是合法PRE）。除了中继消息AVP中携带的PaC原始PANA消息外，PAA还需要处理PaC信息AVP，因此使用PRE可能会对PAA施加额外的存储要求。盗贼预生成有效的PANA数据包需要它是MitM，以便与PaC上的PANA会话状态和属性同步。这样的MitM已经可以干扰EAP和PANA，即使不起到PRE的作用。
An unauthorized node pretending as PAA can spoof the relayed PANA messages to the PRE in order to get them delivered to the PaC. While the harm caused by such spoofed packets are limited (due to the EAP and PANA design with unsecured network operation in mind), the processing of bogus packets can cause processing load on the PaC.
假装为PAA的未经授权节点可以将中继的PANA消息欺骗到PRE，以便将它们传递到PaC。虽然此类伪造数据包造成的危害是有限的（由于EAP和PANA的设计考虑到了不安全的网络操作），但处理伪造数据包可能会在PaC上造成处理负载。
Some of the risks stemming from the aforementioned threats are already handled by the EAP and PANA as described. The residual risks shall be mitigated using additional physical or cryptographic security in the network hosting the PREs and the PAAs. Access control lists implemented on the PRE, PAA, or intermediary firewalls supported by cryptographic or physical authentication/authorization are needed for protecting legitimate PRE and PAAs against rogue ones. Details of the cryptographic mechanisms using IPsec are specified in Section 3. Use of manually configured preshared keys for IPsec between PREs and PAAs does not defend against replayed PANA messages.
如前所述，上述威胁产生的一些风险已经由EAP和PANA处理。应在承载PREs和PAAs的网络中使用额外的物理或加密安全性来缓解剩余风险。需要在加密或物理身份验证/授权支持的PRE、PAA或中间防火墙上实现访问控制列表，以保护合法的PRE和PAA免受流氓攻击。第3节详细说明了使用IPsec的加密机制。在PREs和PAAs之间为IPsec使用手动配置的预共享密钥不会防止重播的PANA消息。
PREs do not need to maintain per-PaC state; therefore, they are robust against resource consumption DoS (Denial-of-Service) attacks.
PRE不需要维护每个PaC状态；因此，它们对资源消耗DoS（拒绝服务）攻击具有很强的鲁棒性。
In the relay operation, the IP address of the PAA that is seen by the PaC (i.e., an IP address of the PRE) is different from the IP address of the PAA that is seen by the authentication server. If an EAP channel binding solution uses the IP address of the PAA as part of channel binding parameters, such a solution must take this into account. Note that the same issue arises even when non-relayed PANA is used and the PAA has one IP address configured on its interface facing the PaC and another IP address on the other interface facing the authentication server.
在中继操作中，PaC看到的PAA的IP地址（即PRE的IP地址）与认证服务器看到的PAA的IP地址不同。如果EAP通道绑定解决方案使用PAA的IP地址作为通道绑定参数的一部分，则此类解决方案必须考虑这一点。请注意，即使使用非中继PANA，并且PAA在其面向PaC的接口上配置了一个IP地址，在另一个面向认证服务器的接口上配置了另一个IP地址，也会出现相同的问题。
As described in Sections 4 and 5, and following the new IANA allocation policy on PANA messages [RFC5872], one Message Type and two PANA AVP Codes have been assigned.
如第4节和第5节所述，根据PANA消息的新IANA分配政策[RFC5872]，已分配一种消息类型和两个PANA AVP代码。
o A Message Type of 5 for PANA-Relay (PRY) message with the 'R' (Request) bit cleared.
o 清除“R”（请求）位的PANA中继（PRY）消息的消息类型为5。
o A standard AVP Code of 10 for PaC-Information AVP.
o 用于PaC信息AVP的标准AVP代码为10。
o A standard AVP Code of 11 for Relayed-Message AVP.
o 用于中继消息AVP的标准AVP代码为11。
The authors would like to thank Vlad Gherghisan, Shohei Watanabe, Richard Kelsey, Rafa Marin Lopez, Margaret Wasserman, Alan DeKok, Ralph Droms, Jari Arkko, Yoshifumi Nishida and Stephen Farrell for their valuable comments.
作者要感谢Vlad Gherghisan、渡边昭平、Richard Kelsey、Rafa Marin Lopez、Margaret Wasserman、Alan DeKok、Ralph Droms、Jari Arkko、Yoshifumi Nishida和Stephen Farrell的宝贵评论。
[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月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
[RFC5191]Forsberg，D.，Ohba，Y.，Patil，B.，Tschofenig，H.，和A.Yegin，“承载网络接入认证（PANA）的协议”，RFC 51912008年5月。
[RFC5192] Morand, L., Yegin, A., Kumar, S., and S. Madanapalli, "DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents", RFC 5192, May 2008.
[RFC5192]Morand，L.，Yegin，A.，Kumar，S.，和S.Madanapalli，“承载网络访问身份验证（PANA）身份验证代理的协议的DHCP选项”，RFC 5192，2008年5月。
[RFC5872] Arkko, J. and A. Yegin, "IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA)", RFC 5872, May 2010.
[RFC5872]Arkko，J.和A.Yegin，“承载网络访问认证（PANA）协议的IANA规则”，RFC 5872，2010年5月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007.
[RFC4944]黑山，G.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 49442007年9月。
[6LoWPAN-ND] Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN)", Work in Progress, June 2011.
[6LoWPAN ND]Shelby，Z.，Chakrabarti，S.，和E.Nordmark，“低功耗和有损网络的邻居发现优化（6LoWPAN）”，正在进行的工作，2011年6月。
[ZIGBEEIP] ZigBee Alliance, "ZigBee IP Specification", ZigBee 095023r10, Work in Progress, July 2010.
[ZIGBEEIP]ZigBee联盟，“ZigBee IP规范”，ZigBee 095023r10，正在进行的工作，2010年7月。
Authors' Addresses
作者地址
Paul Duffy Cisco Systems 200 Beaver Brook Road Boxborough, MA 01719 USA
Paul Duffy Cisco Systems美国马萨诸塞州Boxborough市比弗布鲁克路200号01719
EMail: paduffy@cisco.com
EMail: paduffy@cisco.com
Samita Chakrabarti Ericsson 300 Holger Way San Jose, CA 95135 USA
美国加利福尼亚州圣何塞霍尔格大道300号Samita Chakrabarti Ericsson 95135
EMail: samita.chakrabarti@ericsson.com
EMail: samita.chakrabarti@ericsson.com
Robert Cragie Pacific Gas & Electric Gridmerge Ltd., 89 Greenfield Crescent Wakefield, WF4 4WA UK
Robert Cragie Pacific Gas&Electric Gridmerge Ltd.，89 Greenfield Crescent Wakefield，WF4 4WA UK
EMail: robert.cragie@gridmerge.com
EMail: robert.cragie@gridmerge.com
Yoshihiro Ohba (editor) Toshiba Corporate Research and Development Center 1 Komukai-Toshiba-cho Saiwai-ku, Kawasaki, Kanagawa 212-8582 Japan
大叶吉弘（编辑）东芝公司研发中心1 Komukai Toshiba cho Saiwai ku，川崎，神奈川212-8582日本
Phone: +81 44 549 2127
EMail: yoshihiro.ohba@toshiba.co.jp
Phone: +81 44 549 2127
EMail: yoshihiro.ohba@toshiba.co.jp
Alper Yegin Samsung Istanbul Turkey
土耳其伊斯坦布尔阿尔珀·耶金酒店
EMail: a.yegin@partner.samsung.com
EMail: a.yegin@partner.samsung.com