Protocol for Carrying Authentication for Network Access (PANA) Relay Element
Extracted elements (24)
PANA relay is needed because in ZigBee IP networks using 6LoWPAN, a joining node (PaC) can only use a link-local IPv6 address before authentication completes, while the PAA typically resides in a 6LowPAN Border Router multiple IP hops away. The PRE on the parent node bridges this routing gap without requiring the PaC to have a routable address.
The PRE is designed to maintain no per-PaC state, making it inherently robust against resource-consumption denial-of-service attacks. This is a deliberate architectural choice distinguishing it from stateful relay or proxy designs.
PaC discovery of the PRE uses the standard PAA discovery mechanism defined in RFC 5192. PREs are assumed to be statically configured with PAA IP addresses; dynamic PAA discovery for PREs is out of scope.
This specification assumes at most one PRE exists between a given PaC and PAA. Relay operation on an already-relayed PANA message (i.e., a PRY carrying another PRY payload) is explicitly out of scope.
A PAA that supports this specification MUST be able to process PRY messages for PaC-initiated PANA sessions.
A PRY message MUST NOT be retransmitted by the PRE or the PAA. Retransmission is handled by the PaC or PAA at the PANA layer, resulting in a new PRY carrying the same Relayed-Message AVP.
IKE with preshared secrets SHOULD be supported for key management between PREs and PAAs; IKE with public keys MAY be supported. Manually configured keys suffice functionally but do not defend against replayed messages.
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.
IPsec between PREs and PAAs SHOULD use transport mode and ESP. Because PANA message content is not generally considered confidential, NULL encryption may be used.
PRE-to-PAA security is OPTIONAL; however, if a cryptographic mechanism is supported, it SHOULD be IPsec. When device characteristics preclude IPsec, alternatives such as DTLS or link-layer cryptographic security may be used.
The PRY message SHOULD NOT carry AVPs other than PaC-Information and Relayed-Message.
The Session Identifier and Sequence Number fields of any PRY message MUST be set to zero.
A PANA Relay Element (PRE) sits between a PaC and a PAA, relaying PANA messages between them. The PRE does not maintain per-PaC state; from the PaC's perspective it appears as the PAA. A PRE can serve multiple PAAs and will select one PAA per PaC.
The PANA-Relay (PRY) message (Message Type 5) is sent by the PRE to the PAA or by the PAA to the PRE. It carries exactly one PaC-Information AVP and one Relayed-Message AVP. Its grammar is: PANA-Relay ::= < PANA-Header: 5 > { PaC-Information } { Relayed-Message } *[ AVP ].
This document assigns three new IANA allocations in the PANA registries: Message Type 5 for the PANA-Relay (PRY) message with the 'R' (Request) bit cleared; AVP Code 10 for PaC-Information AVP; and AVP Code 11 for Relayed-Message AVP.
A PRE can delay, drop, spoof, or modify PANA messages in transit, posing threats analogous to an on-path MitM against non-relayed PANA. However, EAP and PANA are designed to operate over unsecured links where such threats already exist, and these threats cannot be leveraged to gain unauthorized access or compromise cryptographic keys.
A rogue PRE can spoof PANA messages on behalf of a victim PaC without needing to be an MitM (unlike non-relayed PANA). However, it cannot complete initial authentication without the PaC's credentials, and post-authentication spoofed messages fail integrity checks when a key-generating EAP method is used.
A rogue PRE sending a spoofed PRY can redirect PAA responses to itself by overwriting the PRE address in the PANA session state. It also imposes additional storage requirements on the PAA for holding the PaC-Information AVP alongside the relayed PANA message.
An unauthorized node impersonating a PAA can deliver spoofed relayed PANA messages to the PaC via the PRE. While harm is limited by EAP/PANA design, processing bogus packets can impose computational load on the PaC.
Use of manually configured preshared keys for IPsec between PREs and PAAs does not defend against replayed PANA messages. Residual risks must be mitigated via additional physical or cryptographic security, such as access control lists backed by authentication.
When EAP channel binding solutions use the PAA's IP address as a channel binding parameter, they must account for the fact that the PaC sees the PRE's IP address as the PAA address, while the authentication server sees the PAA's actual IP address. This same issue can arise with non-relayed PANA on multi-homed PAAs.
When a PRY message is received by the PAA, a new PANA session attribute 'IP address and UDP port number of the PRE' is populated. A session is classified as a relayed PANA session when this attribute has a non-null value; subsequent PAA-originated messages for that session are sent to the PRE rather than directly to the PaC.
The PaC-Information AVP (AVP Code 10) is of type OctetString. It contains an IP address — 16 octets for IPv6 or 4 octets for IPv4 — followed by a 2-octet UDP port number of the PaC, both encoded in network-byte order.
The Relayed-Message AVP (AVP Code 11) is of type OctetString and contains the entire relayed PANA message excluding its UDP and IP headers.