Protocol for Carrying Authentication for Network Access (PANA) Relay Element
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com> Subject: Protocol Action: 'Protocol for Carrying Authentication for Network Access (PANA) Relay Element' to Proposed Standard (draft-ohba-pana-relay-03.txt) The IESG has approved the following document: - 'Protocol for Carrying Authentication for Network Access (PANA) Relay Element' (draft-ohba-pana-relay-03.txt) as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Jari Arkko. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ohba-pana-relay/
Technical Summary The 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, a joining node (PaC) may only be able to use a link-local IPv6 address to communicate with a parent router prior to PANA authentication. The PAA typically resides in a 6LoWPAN Border Router which is often multiple IP hops away from the PaC. The PRE implemented on the parent router is used for relaying PANA messages between the PaC and the PAA in this scenario. Working Group Summary This is a submission from outside the working groups. It has been worked on by a set of individuals focused on Internet of Things deployments. Document Quality We are told that PANA relay (and RFC 5191 of course) is being implemented by some ZigBee vendors and demonstrating interoperability in an IP mesh networking environment. Personnel The Document Shepherd is Margaret Wasserman and the responsible Area Director is Jari Arkko. RFC Editor Note Replace the first paragraph of Section 3 with this: PRE/PAA security is OPTIONAL since PANA messages are designed to be used in untrusted networks, but if cryptographic mechanism is supported, it SHOULD be IPsec. When the device characteristics preclude support for IPsec, an alternative mechanism such as DTLS [REF], 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.