Network Working Group P. Duffy Internet-Draft Cisco Intended status: Standards Track S. Chakrabarti Expires: April 23, 2011 IP Infusion R. Cragie PG&E Y. Ohba (Ed.) Toshiba A. Yegin Samsung October 20, 2010 Protocol for Carrying Authentication for Network Access (PANA) Relay Element draft-ohba-pana-relay-01 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 April 23, 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 April 23, 2011 [Page 1] Internet-Draft PANA Relay Element October 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 . . . . . . . . . . . . . . . 6 3.1. PANA-Relay . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. PANA-Error . . . . . . . . . . . . . . . . . . . . . . . . 6 4. PANA AVPs for Relay Operation . . . . . . . . . . . . . . . . . 7 4.1. PaC-Information AVP . . . . . . . . . . . . . . . . . . . . 7 4.2. Relayed-Message AVP . . . . . . . . . . . . . . . . . . . . 7 4.3. Error-Cause AVP . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6.1. The Error-Cause AVP values . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Duffy, et al. Expires April 23, 2011 [Page 2] Internet-Draft PANA Relay Element October 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 the ZigBee IP architecture (Editor's Note: a reference to the 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 typically 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 messages 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 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. 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 support the relay operation 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 message from the PaC, it creates a PANA- Relay (PRY) message containing a Relayed-Message AVP and a PaC- Duffy, et al. Expires April 23, 2011 [Page 3] Internet-Draft PANA Relay Element October 2010 Information AVP. 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. The PRY message is sent to the PAA. When the PAA receives the PRY, 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 RFC 5191, with the following exceptions: (a) The PAA uses the source IP address and the source port number of the PCI and the source IP address and UDP port number of the PRY to identify the PaC among multiple PCI messages sent from different PaCs. (b) 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". (c) 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 message 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-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. When the PRE receives the PRY message, it retrieves the PAA- originated PANA message from the Relayed-Message 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 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 their incoming or outgoing sequence numbers for request when transmitting or receiving a PRY message. Note that the PANA message carried in a Relayed-Message may be retransmitted by the PaC or PAA, leading to transmission of another PRY carrying the same Relayed-Message. When the PRE or the PAA that receives a PCI does not have sufficient resources to perform PANA authentication, it MAY return a PANA-Error (PER) message with Error-Code "PANA_RESOURCE_SHORTAGE" to the PaC. A PAA-generated PER in response to a relayed PCI is also relayed. Duffy, et al. Expires April 23, 2011 [Page 4] Internet-Draft PANA Relay Element October 2010 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. PaC PRE 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. IP2a is used for communicating with PaC. IP2b is used for communicating with PAA. The two IP address may be the same. IP3 is the IP address of PAA. p1 is PaC-assigned UDP port number. p2 is PRE-assigned UDP port number. P: PaC-Information AVP R: Relayed-Message AVP Figure 1: Example Call Message for PANA Relay Duffy, et al. Expires April 23, 2011 [Page 5] Internet-Draft PANA Relay Element October 2010 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- Message AVP. The PRY message SHOULD NOT carry other AVPs. 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. 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 their incoming or outgoing sequence numbers for request when transmitting or receiving a PRY message. PANA-Relay ::= < PANA-Header: TBD> { PaC-Information } { Relayed-Message } *[ AVP ] 3.2. PANA-Error The PANA-Error (PER) message is sent to notify the peer node of an error caused by the message received from the peer. It contains one Error-Code AVP. The PER message MAY carry other AVPs. PANA-Error ::= < PANA-Header: TBD > { Error-Cause } * [ AVP ] This document specifies only one use case for this message, i.e., the PRE or the PAA may send a PER in response to a PCI when it does not have sufficient resources to perform PANA authentication. In this use case, the PER is sent before establishing initial sequence numbers, assigning a session identifier or establishing a PANA SA. Therefore, both the sequence number and session identifier fields of the PER are set to zero (0), no AUTH AVP is included in the PER and the PER is not retransmitted. Duffy, et al. Expires April 23, 2011 [Page 6] Internet-Draft PANA Relay Element October 2010 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 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. 4.2. Relayed-Message AVP The Relayed-Message (AVP Code TBD) is of type OctetString and contains a relayed PANA message. 4.3. Error-Cause AVP The Error-Cause AVP (AVP Code TBD) is used for indicating the cause of the error associated with the message received by the sender of the PER. The AVP data is of type Unsigned32 The following Error- Cause data value is defined in this document. PANA_RESOURCE_SHORTAGE 1 This error is returned when there is no sufficient resources to perform PANA authentication. 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]. PANA [RFC5191] can be used over unsecure links. EAP and PANA protocols are designed in a way that the PANA messaging does not require cryptographic security during the authentication phase. The only additional payload carried between the PRE and the PAA are the IP address and UDP port number values which are already carried by the UDP/IP headers unsecurely between the PaC and the PRE. Therefore, PRY messages do not require any additional cryptographic protection, whether at the PANA layer or a lower layer. If a future document defines additional payload AVPs for the PRY messages, there may be a need to define additional security for those messages. Error notification in the initial exchange using a PANA-Error message is not protected with a PANA SA and is vulnerable to spoofing attacks. Therefore, the receiver SHOULD use such error notification only as a hint to take an appropriate action to deal with the Duffy, et al. Expires April 23, 2011 [Page 7] Internet-Draft PANA Relay Element October 2010 potentially erroneous situation. 6. IANA Considerations As described in Section 3 and Section 4, and following the new IANA allocation policy on PANA messages [RFC5872], two Message Types and three PANA AVP Codes need to be assigned. o One standard Message Type for PANA-Relay (PRY) message. o One standard Message Type for PANA-Error (PER) message. o One standard AVP Code for PaC-Information AVP. o One standard AVP Code for Relayed-Message AVP. o One standard AVP Code for Error-Cause AVP. 6.1. The Error-Cause AVP values As defined in Section 4.3, the Error-Cause AVP (AVP Code TBD) defines the value 1. All remaining values are available for assignment via IETF Review or IESG Approval [RFC5226]. 7. Acknowledgments The authors would like to thank Vlad Gherghisan, Shohei Watanabe and Richard Kelsey 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. Duffy, et al. Expires April 23, 2011 [Page 8] Internet-Draft PANA Relay Element October 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. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [I-D.ietf-6lowpan-nd] Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor Discovery Optimization for Low-power and Lossy Networks", 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 Duffy, et al. Expires April 23, 2011 [Page 9] Internet-Draft PANA Relay Element October 2010 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 Alper Yegin Samsung Istanbul Turkey Email: alper.yegin@yegin.org Duffy, et al. Expires April 23, 2011 [Page 10]