Network Working Group P. Duffy
Internet-Draft Cisco
Intended status: Standards Track S. Chakrabarti
Expires: March 25, 2011 IP Infusion
R. Cragie
PG&E
Y. Ohba (Ed.)
Toshiba
A. Yegin
Samsung
September 21, 2010
Protocol for Carrying Authentication for Network Access (PANA) Relay
Element
draft-ohba-pana-relay-00
Abstract
This document specifies PANA (Protocol for carrying Authentication
for Network Access) Relay Element functionality which enables PANA
messaging between a PaC (PANA Client) and a PAA (PANA Authentication
Agent) where the two nodes cannot reach each other by means of
regular IP routing.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 25, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Duffy, et al. Expires March 25, 2011 [Page 1]
Internet-Draft PANA Forwarding Element September 2010
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . . 3
2. PANA Relay Element . . . . . . . . . . . . . . . . . . . . . . 3
3. PANA messages for Relay Operation . . . . . . . . . . . . . . . 5
3.1. PANA-Relay . . . . . . . . . . . . . . . . . . . . . . . . 5
4. PANA AVPs for Relay Operation . . . . . . . . . . . . . . . . . 6
4.1. PaC-Information AVP . . . . . . . . . . . . . . . . . . . . 6
4.2. Relayed-PDU AVP . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Duffy, et al. Expires March 25, 2011 [Page 2]
Internet-Draft PANA Forwarding Element September 2010
1. Introduction
PANA (Protocol for carrying Authentication for Network Access)
[RFC5191] is a UDP-based protocol to perform EAP authentication
between a PaC (PANA Client) and a PAA (PANA Authentication Agent).
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 architecture (Editor's Note: a reference to ZigBee IP
specification is to be added here when it is under public review), a
joining-node (PaC) can only use a link-local IPv6 address to
communicate with a parent router prior to PANA authentication. The
PAA resides in a 6LBR (6LowPAN Border Router) [I-D.ietf-6lowpan-nd]
which is often multiple IP hops away from the PaC. The PRE
implemented on the parent router is used for relaying PANA PDUs
between the PaC and the PAA in this scenario.
1.1. Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often 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].
2. PANA Relay Element
The PANA Relay Element (PRE) is a node that is located between the
PaC and the PAA. It is responsible for relaying the PANA PDUs
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. It is
assumed that the PRE's IP address that is reachable from the PaC is
known to the PaC prior to PANA authentication by some means that is
not specified in this document. It is also assumed that the PAA's IP
address that is reachable from the PRE is known to the PRE by some
means that is not specified in this document.
The PRE and the PAA supporting the relay operation function as
follows.
The relay operation requires that a PANA session is initiated by the
PaC, i.e., the first message that the PRE relays for any PANA session
is a PCI (PANA-Client-Initiation) message.
When the PRE receives a PANA PDU from the PaC, it creates a PANA-
Duffy, et al. Expires March 25, 2011 [Page 3]
Internet-Draft PANA Forwarding Element September 2010
Relay (PRY) message containing a Relayed-PDU AVP and a PaC-
Information AVP. The Relayed-PDU AVP encapsulates the entire PANA
PDU received from the PaC. The PaC-Information AVP contains the
PaC's IP address and UDP port number. The PRY message is sent to the
PAA.
When the PAA receives the PRY, it retrieves the PaC-originated PANA
PDU from the Relayed-PDU AVP and the PaC's IP address and UDP port
number from the PaC-Information AVP. The PaC-originated PANA PDU is
processed in the same way as specified in RFC 5191, with the
following exceptions:
(a) The PaC's IP address and UDP port number are maintained in the
PANA session attribute "IP address and UDP port number of the PaC".
(b) The source IP address and UDP port number of the PRY is stored 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.
When the PAA originates a PANA PDU for a relayed PANA session, it
sends a PRY message to the PRE's IP address and UDP port number. The
PRY message includes a Relayed-PDU AVP containing the PAA-originated
PANA PDU and also includes a PaC-Information AVP containing the PaC's
IP address and UDP port number.
When the PRE receives the PRY message, it retrieves the PAA-
originated PANA PDU from the Relayed-PDU and the PaC's IP address and
UDP port number from and PaC-Information AVPs. The PAA-originated
PANA PDU is sent to the PaC's IP address and UDP port number.
The Session Identifier and Sequence Number of a PRY message are set
to zero. A PRY message is never retransmitted by the PRE or the PAA.
The PRE and PAA do not advance its incoming or outgoing sequence
numbers for request when transmitting or receiving a PRY message.
Note that the PANA message carried in a Relayed-PDU may be
retransmitted by the PaC or PAA, leading to transmission of another
PRY carrying the same Relayed-PDU.
If direct IP routing becomes available (e.g., after the successful
PANA authentication as in the case of Zigbee IP), the PaC may choose
to directly communicate with the PAA without use of the relay
operation. The IP address update procedure defined in [RFC5191] may
be performed to switch to non-relay operation.
Figure 1 is an example message flow with a PRE.
Duffy, et al. Expires March 25, 2011 [Page 4]
Internet-Draft PANA Forwarding Element September 2010
PaC(IP1:p1) (IP2a:716)PRE(IP2b:p2) (IP3)PAA srcIP:port->dstIP:port
-------- ------------------------ ------- ----------------------
1. ----PCI---> IP1:p1 -> IP2a:716
2. ----PRY[P{IP1:p1},R{PCI}]---> IP2b:p2 -> IP3:716
3. <---PRY[P{IP1:p1},R{PAR}]---- IP3:716 -> IP2b:p2
4. <----PAR--- IP2a:716 -> IP1:p1
5. ----PAN---> IP1:p1 -> IP2a:716
6. ----PRY[P{IP1:p1},R{PAN}]---> IP2b:p2 -> IP3:716
7. <---PRY[P{IP1:p1},R{PAR}]---- IP3:716 -> IP2b:p2
8. <----PAR--- IP2a:716 -> IP1:p1
9. ----PAN---> IP1:p1 -> IP2a:716
10. ----PRY[P{IP1:p1},R{PAN}]---> IP2b:p2 -> IP3:716
IP1 is the IP address of PaC.
IP2a and IP2b are the IP addresses of PRE. The two IP address
may be the same.
IP3 is the IP address of PAA.
P: PaC-Information AVP
R: Relayed-PDU AVP
Figure 1: Example Call Message for PANA Relay
3. PANA messages for Relay Operation
3.1. PANA-Relay
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-
PDU AVP. The PRY message MAY carry other AVPs.
In a PRE-originated PFY message, the PaC-Information AVP contains an
IP address and the UDP port number of the PANA PDU that was
originated by the PaC and is contained in the Relayed-PDU AVP.
Duffy, et al. Expires March 25, 2011 [Page 5]
Internet-Draft PANA Forwarding Element September 2010
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].
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. The PRE and PAA MUST NOT advance its incoming or
outgoing sequence numbers for request when transmitting or receiving
a PRY message.
PANA-Relay ::= < PANA-Header: TBD>
{ PaC-Information }
{ Relayed-PANA-PDU }
*[ AVP ]
4. PANA AVPs for Relay Operation
4.1. PaC-Information AVP
The PaC-Information AVP (AVP Code TBD) is of type OctetString and
contains an IP address (16-octet for IPv6 address and 4-octet for
IPv4 address) followed by 2-octet UDP port number of the PaC, both
encoded in network-byte order.
4.2. Relayed-PDU AVP
The Relayed-PANA-PDU (AVP Code TBD) is of type OctetString and
contains a relayed PANA PDU.
5. Security Considerations
Since the PRE does not maintain per-PaC state, the PRE is robust
against resource consumption DoS (Deniable of Service) attack. The
security properties of the PaC and PAA remain the same as [RFC5191].
If cryptographic integrity protection is needed for PRY messages, it
MUST be provided by either a PANA layer protection mechanism (TBD) or
a lower-layer protection mechanism using, e.g., IPsec.
(Editor's note: PANA-layer integrity protection for PRY messages
needs more investigation considering that PRY messages are not
retransmitted and therefore sequence numbers are not used for them,
whereas sequence numbers are needed for protecting other PANA
messages using a PANA SA. As a result, PANA-layer integrity
Duffy, et al. Expires March 25, 2011 [Page 6]
Internet-Draft PANA Forwarding Element September 2010
protection for PRY messages may require a different mechanism from
that is defined in [RFC5191]. The authors will continue to
investigate candidate PANA-layer integrity protection mechanisms for
PRY messages and define one in a future revision of the document.)
6. IANA Considerations
As described in Sections Section 3 and Section 4, and following the
new IANA allocation policy on PANA messages [RFC5872], one Message
Type and two PANA AVP Codes need to be assigned.
o One standard Message Type for PANA-Relay (PRY) message.
o One standard AVP Code for PaC-Information AVP.
o One standard AVP Code for Relayed-PDU AVP.
7. Acknowledgments
The authors would like to thank Vlad Gherghisan for valuable
comments.
8. References
8.1. Normative References
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008.
[RFC5872] Arkko, J. and A. Yegin, "IANA Rules for the Protocol for
Carrying Authentication for Network Access (PANA)",
RFC 5872, May 2010.
8.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[I-D.ietf-6lowpan-nd]
Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor
Discovery Optimization for Low-power and Lossy Networks",
Duffy, et al. Expires March 25, 2011 [Page 7]
Internet-Draft PANA Forwarding Element September 2010
draft-ietf-6lowpan-nd-13 (work in progress),
September 2010.
Authors' Addresses
Paul Duffy
Cisco Systems
200 Beaver Brook Road
Boxborough, MA 01719
USA
Email: paduffy@cisco.com
Samita Chakrabarti
IP Infusion
1188 Arquest Street
Sunnyvale, CA
USA
Email: samitac@ipinfusion.com
Robert Cragie
Pacific Gas & Electric
Gridmerge Ltd., 89 Greenfield Crescent
Wakefield, WF4 4WA
UK
Email: robert.cragie@gridmerge.com
Yoshihiro Ohba
Toshiba Corporate Research and Development Center
1 Komukai-Toshiba-cho
Saiwai-ku, Kawasaki, Kanagawa 212-8582
Japan
Phone: +81 44 549 2127
Email: yoshihiro.ohba@toshiba.co.jp
Duffy, et al. Expires March 25, 2011 [Page 8]
Internet-Draft PANA Forwarding Element September 2010
Alper Yegin
Samsung
Istanbul
Turkey
Email: alper.yegin@yegin.org
Duffy, et al. Expires March 25, 2011 [Page 9]
