[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 RFC 6345

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-02

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 . . . . . . . . . . . . . . . 5
     3.1.  PANA-Relay  . . . . . . . . . . . . . . . . . . . . . . . . 6
   4.  PANA AVPs for Relay Operation . . . . . . . . . . . . . . . . . 6
     4.1.  PaC-Information AVP . . . . . . . . . . . . . . . . . . . . 6
     4.2.  Relayed-Message 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 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.

   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



Duffy, et al.            Expires April 23, 2011                 [Page 4]

Internet-Draft             PANA Relay Element               October 2010


   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


3.  PANA messages for Relay Operation






Duffy, et al.            Expires April 23, 2011                 [Page 5]

Internet-Draft             PANA Relay Element               October 2010


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 ]



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.


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].



Duffy, et al.            Expires April 23, 2011                 [Page 6]

Internet-Draft             PANA Relay Element               October 2010


   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.


6.  IANA Considerations

   As described in 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-Message AVP.


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.

8.2.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.




Duffy, et al.            Expires April 23, 2011                 [Page 7]

Internet-Draft             PANA Relay Element               October 2010


   [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 8]

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 9]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/