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

Versions: 00

Network Working Group                                           G. Tolle
Internet-Draft                                     Arch Rock Corporation
Intended status: Informational                           October 8, 2008
Expires: April 11, 2009


         A UDP/IP Adaptation of the ZigBee Application Protocol
                           draft-tolle-cap-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 11, 2009.

Abstract

   This document describes a UDP/IP adaptation of the IEEE 802.15.4-
   based ZigBee Application Protocol that enables IP hosts to
   communicate using the application profiles and data models described
   by that protocol, over a wide range of links.  This modified version
   of the ZigBee Application Protocol is named CAP (Compact Application
   Protocol), and it is intended to provide a complete stack of
   application profiles, data exchange, binding operations, security
   protocols, and discovery to IP-networked hosts and embedded devices.
   The protocol's domain of applicability includes IEEE 802.15.4-based
   6LoWPAN devices, but also those on conventional wired and wireless
   links and emerging powerline communication networks.




Tolle                    Expires April 11, 2009                 [Page 1]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Usage Model  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Terms Used . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.3.  Requirements notation  . . . . . . . . . . . . . . . . . .  8
     1.4.  ZigBee Notice  . . . . . . . . . . . . . . . . . . . . . .  8
   2.  Transport  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.  Bootstrapping  . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Address Replacement  . . . . . . . . . . . . . . . . . . . . .  9
   5.  Core Protocol  . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  Protocol Behavior  . . . . . . . . . . . . . . . . . . . . 12
       5.1.1.  Transmission . . . . . . . . . . . . . . . . . . . . . 12
       5.1.2.  Reception  . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Data Protocol  . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  Management Protocol  . . . . . . . . . . . . . . . . . . . . . 14
     7.1.  Discovery Messages . . . . . . . . . . . . . . . . . . . . 15
     7.2.  Binding Messages . . . . . . . . . . . . . . . . . . . . . 18
     7.3.  Binding Table Cache Messages . . . . . . . . . . . . . . . 20
     7.4.  Network Management Messages  . . . . . . . . . . . . . . . 21
   8.  Security Protocol  . . . . . . . . . . . . . . . . . . . . . . 22
     8.1.  Secure Communication . . . . . . . . . . . . . . . . . . . 22
     8.2.  Key Management Protocol  . . . . . . . . . . . . . . . . . 24
       8.2.1.  Key Management Protocol Examples . . . . . . . . . . . 25
       8.2.2.  Key Management Protocol Messages . . . . . . . . . . . 28
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 30
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 31
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 31
     11.2. Informative References . . . . . . . . . . . . . . . . . . 32
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
   Intellectual Property and Copyright Statements . . . . . . . . . . 33



















Tolle                    Expires April 11, 2009                 [Page 2]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


1.  Introduction

   Embedded networking technologies such as IEEE 802.15.4 [IEEE802154]
   and 6LoWPAN [RFC4944] have enabled a new class of embedded systems to
   operate with native IPv4 and IPv6 [RFC2460] connectivity.  IP enables
   interoperability at the network layer, but does not address the
   desire among users for a common application-layer standard that
   enables administrators of networks including IP-connected embedded
   systems to easily connect devices produced by different vendors.

   The ZigBee Application Layer [ZigBee], and the ZigBee Cluster Library
   [ZigBeeCL] that runs over it, are designed to address this desire for
   devices on a specific wireless link (IEEE 802.15.4).  The ZAL and ZCL
   describe a set of structured communication primitives for exchange of
   data and commands, a protocol for binding and service discovery, a
   security protocol, and a profile system that enables the definition
   of interfaces for specific classes of devices that are designed to
   discover each other and interoperate.  The primary design goal of the
   ZAL and ZCL appears to have been the definition of a compact and low-
   traffic message format in order to support embedded systems attached
   to low-bandwidth lossy networks.  A secondary design goal of the ZAL
   and ZCL appears to have been for a protocol that can be implemented
   using a small amount of code and RAM, to support embedded systems
   running on microcontrollers.  These design principles make the ZAL
   and ZCL particularly well-suited for structured communication among
   networked embedded systems for instrumentation, monitoring, and open-
   loop control.

   However, the ZigBee Application Layer was originally designed to
   operate only over IEEE 802.15.4 wireless networks.  The full ZigBee
   Specification includes the definition of a network layer that also
   operates only over IEEE 802.15.4 wireless networks, and the ZAL is
   defined solely in terms of this network layer and the addressing
   primitives provided by the 802.15.4 link layer.  Furthermore, it does
   not address how such an application protocol is carried out over
   other well-established communication links, nor how a conventional
   TCP/IP or UDP/IP host can participate in such an application
   protocol.

   This document proposes an adaptation of the ZigBee Application Layer
   that enables devices with native UDP/IP stacks to exchange
   application-layer data while employing the higher-level primitives
   defined by the ZAL.  Our name for this adapted version of the ZAL, as
   used within this document, is CAP (Compact Application Protocol).

   CAP is not a "tunneling" mechanism, by which multiple ZigBee networks
   may be interconnected over an IP substrate, in which ZigBee messages
   are passed unmodified.  CAP is also not a "gatewaying" mechanism, by



Tolle                    Expires April 11, 2009                 [Page 3]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   which messages from ZigBee nodes may be modified by an intermediate
   host, possibly with address reassignment or payload modification, and
   placed into an IP message for transmission to other IP hosts.

   CAP is a "port" of the ZigBee Application Layer from its original
   IEEE 802.15.4-specific network layer to a native UDP/IP
   implementation.  ZAL messages are placed into UDP messages, and
   particular modifications to the ZAL protocol are required because the
   substrate is now IP hosts with IP addresses instead of IEEE 802.15.4
   hosts with 802.15.4 addresses.

   By running this "ported" ZAL service, IP hosts at all scales
   (embedded, mobile-class, PC-class, and server-class) can benefit from
   the data, binding, discovery, and profiles defined by the ZAL.

   The designer of a host running CAP may choose to implement the
   Devices and Clusters of any of the published ZigBee Application
   Profiles over CAP, including but not limited to ZigBee Smart Energy
   [ZigBeeSE] and ZigBee Home Automation [ZigBeeHA].  The designer may
   also choose to implement any unpublished ZigBee Application Profiles,
   or define their own Application Profile for a new application domain.

   Several other related application-layer standards exist for providing
   structured communication, binding, discovery, and profiles over IP
   networks, including Devices Profile for Web Services [DPWS] (and its
   underlying Web Services standards) and Universal Plug and Play
   [UPnP].  The ZAL (and CAP) differs from these other standards because
   it was designed to have a compact message format and a simple
   implementation.  By comparison, these two related standards use HTTP
   and XML as a data exchange format.  HTTP/XML is more verbose than the
   binary messages over UDP used by CAP, which may not be suitable for
   low-bandwidth low-power networks.  HTTP/XML requires more host
   resources to encode, decode, and process, which may not be suitable
   for extremely resource-constrained IP-connected hosts running on
   microcontrollers.

1.1.  Usage Model

   An example of a scenario to which CAP may be applied is a "smart
   energy" system -- a connected set of energy consuming devices, energy
   producing or transmitting devices, and human-interactive displays and
   controllers.

   One such smart energy system intended for home use may include a
   number of load controlled appliances, a connected electricity and gas
   meter plus one or more submeters, an interactive wall-mounted
   display, and a host whose purpose is to apply an energy usage policy
   to the devices in the system, sometimes called an "Energy Services



Tolle                    Expires April 11, 2009                 [Page 4]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   Portal".

   Agreement among vendors can result in the production of an
   Application Profile document for the "Smart Energy" application
   domain, which includes a set of device classes that fit this domain,
   and a concrete description of the functionality provided by each
   device.

   The devices implementing this profile document will use the CAP Core
   Protocol to communicate over the network and will use the CAP Data
   Protocol to exchange data.  These protocols will be employed when the
   meters send energy usage information to the display, and when the
   energy services portal sends policy control messages to the load
   control units, for example.  The Security Protocol portions of CAP
   may be used to authenticate, encrypt, and decrypt these Core Protocol
   messages.

   When the network is being created or when new devices are being
   added, the network administrator will use the CAP Management Protocol
   to discover the existence of devices on the network and the
   capabilities of those devices.  Then, the administrator will
   establish communication links between devices by manipulating an
   binding table resident on each device, also with the Management
   Protocol.  This binding table contains IP addresses and ports of peer
   devices running CAP, and Cluster identifiers used to connect
   compatible interfaces.

1.2.  Terms Used

   ZigBee Specification  The original document that describes the ZigBee
      Network Layer and ZigBee Application Layer [ZigBee].

   ZAL (ZigBee Application Layer)  An application-layer protocol and
      profile system for service discovery, binding, security, and
      structured communication.  Originally designed to run over the
      ZigBee Network Layer.  Defined in [ZigBee].

   ZNL (ZigBee Network Layer)  A link-level mesh protocol designed to
      run on the IEEE 802.15.4 link, specified in terms of IEEE 802.15.4
      link layer addresses.  Defined in [ZigBee].

   IEEE 802.15.4  A low-power low-bandwidth link layer, over which
      ZigBee was originally intended to run.

   ZigBee Network Address  An IEEE 802.15.4 link address that is used
      within the ZNL to identify a host.





Tolle                    Expires April 11, 2009                 [Page 5]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   ZCL (ZigBee Cluster Library)  A protocol that runs above the ZAL,
      providing a set of abstractions for remote data access through
      Attributes and Commands.  Also, a public list of well-defined
      interfaces to named units of functionality that can be provided by
      CAP Data Peers, composed of Attributes and Commands.  Defined in
      [ZigBeeCL].

   CAP (Compact Application Protocol)  This document's name for the
      adapted version of the ZigBee Application Layer that runs over
      UDP/IP.

   APS (ZigBee Application Support Layer)  The lowest layer of the ZAL,
      defined in [ZigBee].

   Core Protocol  The lowest level of CAP, that corresponds to the
      ZigBee Application Support Layer.

   CAP Address Record  A structure that contains an IPv4 address and
      port, IPv6 address and port, or DNS hostname and port, which is
      used to replace the ZigBee addressing used in the original ZAL.

   Data Peer  The basic service role that a CAP host may play,
      exchanging APS messages, possibly fragmented or secured, and
      containing ZCL operations for Command and Attribute transmission
      and reception.

   Data Protocol  The layer of CAP that corresponds to the ZCL protocol,
      and runs above the Core Protocol layer.

   Discovery  An interaction that allows a CAP Data Peer to send its
      Device types and Cluster lists over the network, and allows an
      Administrator to look up this information in a Discovery Cache.

   Discovery Cache  A CAP host that provides storage and querying for
      the service information provided by CAP Data Peers by responding
      to the Discovery Protocol Messages described in the Management
      Protocol section of this document.

   Binding  A connection between two CAP Data Peers that share a common
      Cluster, stored in a Binding Table on the Data Peer that needs to
      contact the other Data Peer.

   ZDP (ZigBee Device Profile)  The subset of the ZAL that performs
      management operations like discovery and binding.  Defined in
      [ZigBee].






Tolle                    Expires April 11, 2009                 [Page 6]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   Management Protocol  The layer of CAP that corresponds to the ZigBee
      Device Profile, providing a protocol for discovery and binding.

   Trust Center  A CAP host that permits joining and leaving of a
      Security Domain by distributing a shared Domain Key, and acts as a
      key-escrow center to assign shared Link Keys to pairs of nodes
      that need to communicate securely.

   Security Protocol  The layer of CAP that corresponds to the APS Layer
      Security, including a header that may be inserted into an APS
      message and a set of messages for key exchange.

   Administrator  A CAP host that initiates binding and discovery
      operations in order to establish communication relationships among
      Data Peers.

   Binding Coordinator  A CAP host that assists nodes in establishing
      relationships without an Administrator's involvement, by
      responding to the End Device Bind messages described in the
      Management Protocol section.

   Binding Table Cache  A CAP host that holds a copy of the binding
      information normally resident in the individual nodes' binding
      tables, which is obtained by responding to the Binding Table Cache
      messages described in the Management Protocol section.

   Application Profile  A document that specifies an application domain
      consisting of a set of Devices that are intended to work together,
      and the well-defined Cluster interfaces needed by these devices to
      communicate.

   Device  A named object that implements a set of Cluster interfaces to
      provide app-layer functionality.

   Cluster  A specific remote interface that provides a single unit of
      functionality composed of Attributes and Commands.

   Attribute  A definition of a single data value that may be produced
      or consumed by a device implementing a Cluster.

   Command  A definition of a single message that may be sent between
      devices implementing a Cluster intended to initiate an operation.

   Datatype  A definition of a concrete representation of a value
      contained in an Attribute or Command.






Tolle                    Expires April 11, 2009                 [Page 7]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   Endpoint  An identifier used to enable multiple Devices to be
      implemented by a single CAP Data Peer.

1.3.  Requirements notation

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

1.4.  ZigBee Notice

   In order to represent a product as ZigBee, ZigBee Compliant, ZigBee
   Certified or similar or to use any ZigBee Alliance intellectual
   property (including, without limitation, the ZigBee Specification,
   ZigBee Profile Specifications, ZigBee Test Plans, ZigBee trademarks
   or logos) for any commercial purpose, proper licensing must be
   obtained by joining the ZigBee Alliance or entering into license
   agreements with the relevant members of the ZigBee Alliance.


2.  Transport

   As specified, the ZigBee Application Layer messages are transmitted
   by the ZigBee Network Layer.  The first basic modification of the
   ZigBee Application Layer is to embed its messages in UDP datagrams
   instead of ZigBee Network Layer frames.  Thus, CAP messages are
   transmitted as datagrams over UDP/IP.  Note that the ZigBee
   Application Layer messages, and thus the CAP messages, are specified
   to be little-endian.

   A CAP peer will typically need to be able to receive unsolicited
   notifications, and to do so, the CAP peer MUST bind to the chosen UDP
   port for listening.  If the chosen port is unavailable on the host,
   then an alternate port MAY be chosen and used when communicating,
   binding, and registering.  In the common case of a CAP client-server
   system, the chosen listening port SHOULD also be used as the source
   port for transmissions.  Transmissions from client-only systems MAY
   be sent from an ephemeral port.


3.  Bootstrapping

   Because CAP devices often do not contain human interfaces, other
   mechanisms are employed to provide the IP addresses and ports of CAP
   nodes in the network to other CAP nodes.  CAP provides a Discovery
   Cache, which other nodes can use to look up the addresses of CAP
   nodes, but the IP address and port of the Discovery Cache is
   typically obtained through means outside of CAP.  In addition, the IP



Tolle                    Expires April 11, 2009                 [Page 8]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   address of the Trust Center, Binding Coordinator, and Binding Table
   Cache are also discovered by the CAP Data Peers typically through
   means outside of CAP.

   Preconfiguration  When the IP addresses or DNS names of the CAP
      servers are well-known, they can be configured into the CAP Data
      Peers.

   DHCP Option  If a DHCP server is available, it can provide the
      addresses of these servers via a DHCP option to be specified at
      some future time, as is done today to assign a DNS server address
      [RFC2131].

   DNS-Based Service Discovery  If a DNS server is available, the CAP
      Data Peer can look up a SRV record containing a type for the CAP
      protocol to be specified at some future time, with an associated
      set of keys in a TXT record that describe the CAP server
      functionality available on the host [I-D.cheshire-dnsext-dns-sd].
      This service discovery operation can run via standard unicast DNS
      in the wide area case, or multicast DNS in the local network case
      [I-D.cheshire-dnsext-multicastdns].

   CAP Server Discovery  If these mechanisms are not available, the CAP
      Data Peer can send the CAP Server Discovery message via IPv4
      subnet broadcast or IPv6 link-local multicast [RFC2373] to
      discover any CAP Servers available on the local network.


4.  Address Replacement

   As specified, the ZigBee Application Layer protocol identifies nodes
   in the network either by their globally-unique 64-bit IEEE 802.15.4
   EUI-64 or by their locally-unique 16-bit IEEE 802.15.4 short address.
   The second basic modification applied to the ZigBee Application Layer
   is to replace each use of an 802.15.4-specific address with a CAP
   Address Record, which can contain an IPv4 address plus UDP port, IPv6
   address plus UDP port, or DNS Fully-Qualified Domain Name [RFC1034]
   plus UDP port.

   The CAP Address Record has five possible formats, which are
   distinguished by the value of the leading Type byte:

   Source Address (0x01)  A message sender includes this address record
      type as a placeholder in a message to indicate that the intended
      address is its own source IP address and source port.  When this
      record type is encountered in a received network message, the
      processing node MUST use the source IP address and source port
      contained in the message for any further operations that include



Tolle                    Expires April 11, 2009                 [Page 9]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


      the address.  Examples of such operations include registration of
      discovery information or addition of binding table entries.  This
      address record type is only intended for use in a message, and
      MUST NOT be stored in any in-memory or persistent table such as a
      discovery cache table or a binding table.  Instead, the actual
      source IP address and source port MUST be stored in the table,
      using one of the other non-placeholder address types.

   +-+-+-+-+-+-+-+-+
   |  Type = 0x01  |
   +-+-+-+-+-+-+-+-+

   Destination Address (0x02)  A message sender includes this address
      record type as a placeholder in a message to indicate that the
      actual address is the destination IP address and destination port
      of the message.  When this record type is encountered in a
      received network message, the processing node MUST use the
      destination IP address and destination port contained in the
      message for any further operations that include the address.
      Examples of such operations include query of discovery
      information.  This address record type is only intended for use in
      a message, and MUST NOT be stored in any in-memory or persistent
      table such as a discovery cache table or binding table.  Instead,
      the actual destination IP address and destination port MUST be
      stored in the table, using one of the other non-placeholder
      address record types.

   +-+-+-+-+-+-+-+-+
   |  Type = 0x02  |
   +-+-+-+-+-+-+-+-+

   IPv4 Address (0x03)  This address record type contains a single IPv4
      address and port.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 0x03  |                  IPv4 Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |             Port              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 Address (0x04)  This address record type contains a single IPv6
      address and port.









Tolle                    Expires April 11, 2009                [Page 10]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 0x04  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             IPv6 Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |             Port              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   DNS Name (0x05)  This address record type contains a single DNS
      hostname.  It may be stored in a table, but will have to be
      resolved to an IP address prior to every communication with the
      referenced node.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 0x05  |    Length     |   DNS Name (variable length)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Port              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The CAP Address Record is always represented in standard network byte
   order (big-endian) when included in a CAP message.


5.  Core Protocol

   The basic CAP UDP message contains the ZigBee Application Layer APS
   frame with the format defined in Section 2.2.5 "Frame Formats" of the
   ZigBee Specification, and all nested payloads and additional headers
   that may be placed within the APS frame.  This embedded frame is
   termed the CAP Core Protocol message.

   The basic CAP interaction over UDP:

            Data Peer                        Data Peer
      on IP Address X : Port Y          on IP Address X' : Port Y'
                |                                 |
                |       CAP APS Frame in UDP      |
                |===============================> |
                |                                 |
                |  (optional) CAP APS Ack in UDP  |
                | <-------------------------------|
                |                                 |





Tolle                    Expires April 11, 2009                [Page 11]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


5.1.  Protocol Behavior

5.1.1.  Transmission

   CAP Core Protocol messages are transmitted from one IP host to
   another IP host.  All three ZigBee APS Frame Types are allowed (APS
   Data, APS Command, APS Acknowledgment), and transmission proceeds
   according to the rules in section 2.2.5.1 of the ZigBee
   Specification, except as described below.

   The Delivery Mode sub-field of the APS header is typically set to
   0x00 (Normal Unicast Delivery), unless the destination IP address is
   a multicast address, in which case this field is set to 0x10
   (Broadcast).  Indirect delivery assumes a ZigBee Network Layer, and
   thus this option is not used in CAP.  Because Group delivery
   interacts with the ZigBee Network Layer via 16-bit group addresses,
   CAP uses the ZigBee mode of operation described in Section 2.2.8.4.1
   of the ZigBee Specification when nwkUseMulticast is true.  Thus,
   Group delivery is reduced to Broadcast delivery with a multicast
   destination IP address and a destination CAP endpoint of 0xFF.

   The upper-layer sender of the message specifies whether or not
   security should be used and with which type of key, and whether or
   not reliable transfer with acknowledgments should be used.

   If secure transmission is requested, then the device shall follow the
   security processing steps specified in Section 4.4.1.1 of the ZigBee
   Specification, as modified by the Security Protocol section in this
   document, to generate a new message containing security headers.

   If reliable transfer is requested, then the device shall set the
   Acknowledgment Request bit in the APS header, send the message, and
   wait up to ACK_WAIT_DURATION seconds for the acknowledgment message.
   If the device does not receive an acknowledgment in that time with a
   matching APS Counter value, it will retransmit the message (with the
   same APS Counter value as before) up to ACK_MAX_RETRIES times.  If
   all transmission attempts fail, the device shall stop attempting
   transmission and signal the error to the upper layer.

5.1.2.  Reception

   The basic CAP message is received by a UDP/IP host.

   If the message is secured, security processing then performed as
   specified in Section 4.4.1.2 of the ZigBee Specification, modified by
   the Security Protocol section in this document.  If security
   processing fails, then the message MUST be discarded.




Tolle                    Expires April 11, 2009                [Page 12]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   The source IP address, source port, and APS Counter field MUST be
   used to determine whether this message is a duplicate of a previously
   received message.  If the message is determined to be a duplicate,
   then the message MUST be discarded.

   If an acknowledgment has been requested by setting the Acknowledgment
   Request sub-field, the CAP implementation must generate the
   appropriate APS acknowledgment frame according to the rules in
   Section 2.2.5.2.3.1 of the ZigBee Specification, and send it to the
   source port, and source IP address of the received CAP message.

   The message can now be processed by the next upper layer.  If the
   message is an APS Command message, then it will be processed by the
   Security layer.  If the message is a Data message, then the
   destination endpoint will be used to decide which layer processes the
   message.  If the destination endpoint is 0, the CAP Management
   Protocol layer will process it.  Otherwise, the CAP Data Protocol
   layer will process it.  The implementations of all upper layers must
   have access to the values contained in all the fields of this
   message, in particular the source and destination endpoint
   identifiers, cluster identifier, and profile identifier.


6.  Data Protocol

   The CAP Data Protocol is contained within the APS Payload section of
   the CAP Core Protocol message.  The Data Protocol message contains
   the ZCL Command Frame, as defined in section 2.3 of the ZigBee
   Cluster Library Specification.  Hosts communicating with the CAP Data
   Protocol are termed Data Peers.

   All ZCL Commands (e.g.  Read, Write, Report, Configure Reporting,
   Discover Attributes) defined in Section 2.4 of the ZigBee Cluster
   Library Specification are valid for inclusion in the ZCL Payload
   section of the Data Protocol frame.

   The behavior upon transmission and reception of these Data Protocol
   frames must follow the rules in Section 2.3 and Section 2.4 of the
   ZigBee Cluster Library Specification.

   Because none of the ZCL Commands contain addresses, and only refer to
   data objects, none of the message formats require modification to run
   within the CAP context.








Tolle                    Expires April 11, 2009                [Page 13]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   Example of Data Protocol interactions over UDP/IP

   Data Peer                       Data Peer                  Data Peer
     |                                 |                          |
     |        ZCL Read Attributes      |                          |
     |===============================> |                          |
     |                                 |                          |
     |  (optional) CAP APS Ack in UDP  |                          |
     | <-------------------------------|                          |
     |                                 |                          |
     |   ZCL Read Attributes Response  |                          |
     | <===============================|                          |
     |                                 |                          |
     |  (optional) CAP APS Ack in UDP  |                          |
     |-------------------------------> |                          |
     |                                 |   ZCL Report Attributes  |
     |                                 |========================> |
     |                                 |                          |
     |                                 |   (optional) APS Ack     |
     |                                 | <------------------------|


7.  Management Protocol

   The CAP Management Protocol is contained within the APS Payload
   section of the CAP Core Protocol message.  The Management Protocol
   message contains the ZigBee Device Profile (ZDP) Command Frame, as
   defined in Section 2.4.2.8 of the ZigBee Specification.

   The Management Protocol contains the ZigBee Device Profile Client
   Services and Server Services messages defined in Section 2.4.3 and
   Section 2.4.4 of the ZigBee Specification, with certain exceptions
   described below.  Exceptions are either:

   o  exclusion of specific messages that define operations that apply
      only to the original IEEE 802.15.4-based network layer and link
      layer, and cannot be modified to support IP networks

   o  modifications of specific messages to replace IEEE 802.15.4-based
      addressing with IP addressing











Tolle                    Expires April 11, 2009                [Page 14]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


7.1.  Discovery Messages

   Example of Management Protocol for Registration of Discovery
   Information with Discovery Cache

   Discovery                          Joining
    Cache                            Data Peer            Administrator
      |                                 |                          |
      |        Discovery_store_req      |                          |
      | <===============================|                          |
      |                                 |                          |
      |        Discovery_store_rsp      |                          |
      |===============================> |                          |
      |                                 |                          |
      |                                 |                          |
      |        Node_Desc_store_req      |                          |
      | <===============================|                          |
      |                                 |                          |
      |        Node_Desc_store_rsp      |                          |
      |===============================> |                          |
      |                                 |                          |
      |(store all data with store reqs) |                          |
      |                                 |                          |

   Example of Management Protocol for Request of Discovery Information
   from Discovery Cache

   Discovery
    Cache                           Data Peer             Administrator
      |                                 |                          |
      |                    Node_Desc_req( Data Peer )              |
      | <==========================================================|
      |                                 |                          |
      |                    Node_Desc_rsp( Data Peer )              |
      |==========================================================> |
      |                                 |                          |

   Example of Management Protocol for Request of Discovery Information
   from the Node.

   Discovery
    Cache                            Data Peer            Administrator
      |                                 |                          |
      |                                 |       Node_Desc_req()    |
      |                                 | <========================|
      |                                 |                          |
      |                                 |       Node_Desc_rsp()    |
      |                                 |========================> |



Tolle                    Expires April 11, 2009                [Page 15]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   NWK_addr_req/rsp (ClusterID=0x0000/0x8000)  This message pair is not
      used in CAP, because it only maps between the two types of IEEE
      802.15.4 addresses, and is not needed when both peers are only
      using IP addresses

   IEEE_addr_req/rsp (ClusterID=0x0001/0x8001)  This message pair is
      also not used in CAP, as it is the inverse of NWK_addr_req.

   Node_Desc_req/rsp (ClusterID=0x0002/0x8002)  The request and response
      each contain a single ZigBee Network Address in a field named
      NWKAddrOfInterest, which is the address of the node whose Node
      Descriptor is being requested.  For use in CAP, replace the
      NWKAddrOfInterest with a single CAP Address Record.

   Power_Desc_req/rsp (ClusterID=0x0003/0x8003)  Replace
      NWKAddrOfInterest with CAP Address Record in both request and
      response.

   Simple_Desc_req/rsp (ClusterID=0x0004/0x8004)  Replace
      NWKAddrOfInterest with CAP Address Record in both request and
      response.

   Active_EP_req/rsp (ClusterID=0x0005/0x8005)  Replace
      NWKAddrOfInterest with CAP Address Record in both request and
      response.

   Match_Desc_req/rsp (ClusterID=0x0006/0x8006)  Replace
      NWKAddrOfInterest with CAP Address Record in both request and
      response.

   Complex_Desc_req/rsp (ClusterID=0x0010/0x8010)  Replace
      NWKAddrOfInterest with CAP Address Record in both request and
      response.

   User_Desc_req/rsp (ClusterID=0x0011/0x8011)  Replace
      NWKAddrOfInterest with CAP Address Record in both request and
      response.

   Discovery_Cache_req (ClusterID=0x0012/0x8012)  This request message
      is sent to a node or to a multicast address to determine whether
      the node supports the Discovery Cache service.  In the ZigBee
      Specification, the message contains the two source ZigBee Network
      Addresses, to which the Discovery_Cache_rsp will be sent.  In CAP,
      replace these two addresses with a single CAP Address Record
      representing the sender of the message.  The response can be used
      as-is, because it does not contain any addresses.





Tolle                    Expires April 11, 2009                [Page 16]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   Device_annce (ClusterID=0x0013)  This message is not used in CAP,
      because it relates solely to ZigBee Network Layer address
      assignment.

   User_Desc_set/conf (ClusterID=0x0014/0x8014)  Replace
      NWKAddrOfInterest with CAP Address Record in both request and
      response.

   System_Server_Discovery_req/rsp (ClusterID=0x0015)  This message pair
      does not contain any addresses, and so it is used as-is.  However,
      this message should only be used as a fallback for multicast
      server address discovery in CAP.  Typically, server address
      discovery should performed using other out-of-band IP mechanisms,
      including but not limited to pre-assignment of the address, DHCP
      delivery of the address, or DNS Service Discovery to obtain the
      address.

   Discovery_store_req/rsp (ClusterID=0x0016/0x8016)  Replace the two
      Local Device ZigBee Network Addresses with a single CAP Address
      Record in the request.  The response can be used as-is.

   Node_Desc_store_req/rsp (ClusterID=0x0017/0x8017)  Replace the two
      Local Device ZigBee Network Addresses with a single CAP Address
      Record in the request.  The response can be used as-is.

   Power_Desc_store_req/rsp (ClusterID=0x0018/0x8018)  Replace the two
      Local Device ZigBee Network Addresses with a single CAP Address
      Record in the request.  Remove the IEEEAddr from the response,
      because it is not needed.

   Active_EP_store_req/rsp (ClusterID=0x0019/0x8019)  Replace the two
      Local Device ZigBee Network Addresses with a single CAP Address
      Record in the request.  The response can be used as-is.

   Simple_Desc_store_req/rsp (ClusterID=0x001a/0x801a)  Replace the two
      Local Device ZigBee Network Addresses with a single CAP Address
      Record in the request.  The response can be used as-is.

   Remove_node_cache_req/rsp (ClusterID=0x001b/0x801b)  Replace the two
      Local Device ZigBee Network Addresses with a single CAP Address
      Record in the request.  The response can be used as-is.

   Find_node_cache_req/rsp (ClusterID=0x001c/0x801c)  Replace the two
      Local Device ZigBee Network Addresses with a single CAP Address
      Record in the request.  In the response, replace CacheNWKAddress
      with a CAP Address Record representing the address of the
      Discovery Cache holding the information.  Replace the two "device
      of interest" addresses with a single CAP Address Record



Tolle                    Expires April 11, 2009                [Page 17]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


      representing the device being queried for.

   Extended_Simple_Desc_req/rsp (ClusterID=0x001d/0x801d)  Replace
      NWKAddrOfInterest with CAP Address Record in both request and
      response.

   Extended_Active_EP_req/rsp (ClusterID=0x001e/0x801e)  Replace
      NWKAddrOfInterest with CAP Address Record in both request and
      response.

7.2.  Binding Messages

   Example of Management Protocol for Administratively Binding Two Data
   Peers Together


     Data                                                         Data
    Peer X                        Administrator                  Peer Y
      |                                 |                          |
      |    Bind_req( Cluster, Y )       |                          |
      | <===============================|                          |
      |                                 |                          |
      |           Bind_rsp              |                          |
      |===============================> |                          |
      |                                 |                          |
      |                   ZCL Report Attributes( Cluster )         |
      |==========================================================> |
      |                                 |                          |























Tolle                    Expires April 11, 2009                [Page 18]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   Example of Mangement Protocol for End Device Binding Assisted by the
   Binding Coordinator


     Data                            Binding                      Data
     Peer                          Coordinator                    Peer
      |                                 |                          |
      |      End_Device_Bind_req        |                          |
      |===============================> |                          |
      |                                 |    End_Device_Bind_req   |
      |                                 | <========================|
      |       End_Device_Bind_rsp       |                          |
      | <===============================|   End_Device_Bind_rsp    |
      |                                 |========================> |
      |           Unbind_req            |                          |
      | <===============================|                          |
      |           Unbind_rsp            |                          |
      |===============================> |                          |
      |                                 |       Unbind_req         |
      |                                 |========================> |
      |                                 |       Unbind_rsp         |
      |                                 | <========================|
      |           Bind_req              |                          |
      | <===============================|                          |
      |           Bind_rsp              |                          |
      |===============================> |                          |
      |                                 |         Bind_req         |
      |                                 |========================> |
      |                                 |         Bind_rsp         |
      |                                 | <========================|
      |                                 |                          |
      |                       ZCL Report Attributes                |
      |==========================================================> |
      |                                 |                          |

   End_Device_Bind_req/rsp (ClusterID=0x0020/0x8020)  In the request,
      replace the BindingTarget field with a CAP Address Record
      representing the address of the node that will hold the binding
      table entry (typically the node's own address, unless a binding
      table cache is in use).  Replace the SrcIEEEAddress field with
      another CAP Address Record representing the source address of the
      binding, which is the node's own address.  The response just
      contains a Status field, so it may be used as-is.

   Bind_req/rsp (ClusterID=0x0021/0x8021)  In the request, replace the
      SrcAddress field with a CAP Address Record containing the source
      address of the binding.  Replace the DstAddrMode field and
      DstAddress field with a single CAP Address Record representing the



Tolle                    Expires April 11, 2009                [Page 19]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


      destination address of the binding.  The DstEndp field must be
      present.  The response just contains a Status field, so it may be
      used as-is.

   Unbind_req (ClusterID=0x0022)  In the request, replace the SrcAddress
      field with a CAP Address Record containing the source address of
      the binding.  Replace the DstAddrMode field and DstAddress field
      with a single CAP Address Record representing the destination
      address of the binding.  The DstEndp field must be present.  The
      response just contains a Status field, so it may be used as-is.

7.3.  Binding Table Cache Messages

   Bind_Register_req/rsp (ClusterID=0x0023/0x8023)  In the request,
      replace the NodeAddress field with a single CAP Address Record.
      In each element of the BindingTableList array field in the
      response, replace the SrcAddress field with a CAP Address Record
      containing the source address of the binding, and replace the
      DstAddrMode field and DstAddress field with a single CAP Address
      Record representing the destination address of the binding.  The
      DstEndp field must be present in each entry.

   Replace_Device_req/rsp (ClusterID=0x0024/0x8024)  In the request,
      replace the OldAddress field with a single CAP Address Record.
      Replace the NewAddress field with a single CAP Address Record.
      The response just contains a Status field, so it may be used
      as-is.

   Store_Bkup_Bind_Entry_req/rsp (ClusterID=0x0025/0x8025)  In the
      request, replace the SrcAddress field with a CAP Address Record
      containing the source address of the binding.  Replace the
      DstAddrMode field and DstAddress field with a single CAP Address
      Record representing the destination address of the binding.  The
      DstEndp field must be present.  The response just contains a
      Status field, so it may be used as-is.

   Remove_Bkup_Bind_Entry_req/rsp (ClusterID=0x0026/0x8026)  In the
      request, replace the SrcAddress field with a CAP Address Record
      containing the source address of the binding.  Replace the
      DstAddrMode field and DstAddress field with a single CAP Address
      Record representing the destination address of the binding.  The
      DstEndp field must be present.  The response just contains a
      Status field, so it may be used as-is.

   Backup_Bind_Table_req/rsp (ClusterID=0x0027/0x8027)  In each element
      of the BindingTableList array field in the request, replace the
      SrcAddress field with a CAP Address Record containing the source
      address of the binding, and replace the DstAddrMode field and



Tolle                    Expires April 11, 2009                [Page 20]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


      DstAddress field with a single CAP Address Record representing the
      destination address of the binding.  The DstEndp field must be
      present in each entry.  The response may be used as-is.

   Recover_Bind_Table_req/rsp (ClusterID=0x0028/0x8028)  This request
      can be used as-is, because it does not include any addresses.  In
      each element of the BindingTableList array field in the response,
      replace the SrcAddress field with a CAP Address Record containing
      the source address of the binding, and replace the DstAddrMode
      field and DstAddress field with a single CAP Address Record
      representing the destination address of the binding.  The DstEndp
      field must be present in each entry.

   Backup_Source_Bind_req/rsp (ClusterID=0x0029/0x8029)  In the request,
      replace each element of the SourceTableList with a CAP Address
      Record.  The response just contains a Status field, so it may be
      used as-is.

   Recover_Source_Bind_req/rsp (ClusterID=0x002a/0x802a)  This request
      can be used as-is, because it does not include any addresses.  In
      the response, replace each element of the SourceTableList with a
      CAP Address Record.

7.4.  Network Management Messages

   Mgmt_NWK_Disc_req/rsp (ClusterID=0x0030/0x8030)  This message pair is
      not used in CAP, because it only relates to the ZigBee Network
      Layer.

   Mgmt_Lqi_req/rsp (ClusterID=0x0031/0x8031)  This message pair is not
      used in CAP, because it is just a request for a table of IEEE
      802.15.4 link quality measurements.

   Mgmt_Rtg_req/rsp (ClusterID=0x0032/0x8032)  This message pair is not
      used in CAP, because it is a just a request for a table of ZigBee
      Network Routes.

   Mgmt_Bind_req/rsp (ClusterID=0x0033/0x8033)  This request is used
      as-is.  In each element of the BindingTableList array field in the
      response, replace the SrcAddress field with a CAP Address Record
      containing the source address of the binding, and replace the
      DstAddrMode field and DstAddress field with a single CAP Address
      Record representing the destination address of the binding.  The
      DstEndp field must be present in each entry.







Tolle                    Expires April 11, 2009                [Page 21]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   Mgmt_Leave_req/rsp (ClusterID=0x0034/0x8034)  This message pair is
      not used in CAP, because it is a request to leave a ZigBee
      Network.

   Mgmt_Direct_Join_req/rsp (ClusterID=0x0035/0x8035)  This message pair
      is not used in CAP, because it is a request to join a ZigBee
      Network.

   Mgmt_Permit_Joining_req/rsp (ClusterID=0x0036/0x8036)  This message
      pair is not used in CAP, because it is a request to enable another
      node to permit nodes to join a ZigBee network.

   Mgmt_Cache_req/rsp (ClusterID=0x0037/0x8037)  This request is used
      as-is.  In each element of the DiscoveryCacheList array field in
      the response, replace the two ZigBee Addresses with a single CAP
      Address Record.

   Mgmt_NWK_Update_req/rsp (ClusterID=0x0038/0x8038)  This message pair
      is not used in CAP, because it only relates to the ZigBee Network
      Layer.


8.  Security Protocol

   The CAP Security Protocol is based on the ZigBee APS Layer Security
   defined in Section 4.4 of the ZigBee Specification.

   Because all dependencies on the ZigBee Network Layer have removed in
   CAP, the adapted Security Protocol is used only between nodes that
   can already reach each other over the IP network layer.  In general,
   ZigBee Nodes rely on their Network Layer parent to authenticate with
   the Trust Center on their behalf.  In CAP, this model is not used.  A
   node may initiate secure communications or authenticate itself to the
   Trust Center at any time after joining the IP Network.

8.1.  Secure Communication

   The basic element of the Security Protocol is a Security Header that
   may be included in the Core Protocol message, which corresponds to
   the Auxiliary Frame Header defined in Section 4.5.1 of the ZigBee
   Specification.  This Security Header is included after the Core
   Protocol header, and a Security Message Authentication Code is
   included after the payload of the message.  These headers contain
   authentication and encryption information needed to verify or decrypt
   the payload.  Authenticated and encrypted communication may occur
   between any two CAP nodes using shared keys.  In CAP, the Extended
   Nonce bit MUST be set to 1, because a Source Address is always
   included in the nonce.



Tolle                    Expires April 11, 2009                [Page 22]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   Secure communication may proceed between any pair of CAP nodes, as
   long as they share one of the three ZigBee key types defined in
   Section 4.2.1.3 of the ZigBee Specification: a Link Key, a Master
   Key, or a Network Key. All three key types are 128-bits in size.  The
   Link Key and Master Key are only shared to a single pair of nodes,
   and in CAP, the endpoints are represented by CAP Address Records.
   The Network Key is defined by the ZigBee Standard as a key shared
   between all nodes within the IEEE 802.15.4 network, and available for
   use by both the ZigBee Network Layer and the ZigBee Application
   Layer.  In the absence of a ZigBee Network Layer, the Network Key is
   redefined here as a Domain Key that is shared between a set of CAP
   devices that comprise a common Security Domain, defined solely as the
   set of CAP devices communicating with a particular Trust Center host
   and sharing a common Domain Key.

   The rules for generating the Security Header when performing security
   processing on outgoing messages is defined in Section 4.4.1.1 of the
   Zigbee Specification.  Because the Domain Key does not depend on any
   addresses, it may be used exactly as defined to secure both unicast
   and multicast transmissions.  Link Keys and Master Keys shared
   between the message sender and particular devices, and are stored by
   CAP in a table called the "apsDeviceKeyPairSet", defined in Section
   4.4.10 of the ZigBee Specification.  For CAP purposes, each key-pair
   descriptor shall have the following fields instead of those defined
   in Table 4.37:

   DeviceAddress  is the CAP Address Record containing the remote
      address of the CAP peer.

   MasterKey  is the 16-byte value of the master key shared with the
      peer at DeviceAddress

   LinkKey  is the 16-byte value of the link key shared with the peer at
      at DeviceAddress

   OutgoingFrameCounter  is an unsigned 32-bit counter for use with this
      key

   IncomingFrameCounter  is an unsigned 32-bit counter corresponding to
      the DeviceAddress

   In Step 2 of the Outgoing Frame processing steps, the APS layer shall
   always apply security when security is requested, because ZigBee
   Network Layer security does not exist in CAP.

   In Step 4, the CAP implementation shall internally maintain the
   Security Level that is in use among the devices within the Security
   Domain.



Tolle                    Expires April 11, 2009                [Page 23]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   The Security Auxiliary Header shall be constructed according to the
   rules in Steps 5 through 11.  The CAP implementation must maintain an
   8-byte Source Identifier, and use it when constructing the nonce N as
   defined in Section 4.5.2.2.  This source identifier MUST be derived
   from an available link-layer identifier, like an EUI-64, or a MAC-48
   that has been expanded into an EUI-64 according to the rules defined
   in [RFC5342].  This same Source Identifier must then be included in
   the Source Address field of the Security Auxiliary Header, and the
   Extended Nonce subfield must be set to 1.

8.2.  Key Management Protocol

   The ZigBee Application Layer includes a Trust Center, which is
   preserved in CAP.  The Trust Center is responsible for:

   o  accepting authentication requests from CAP nodes and maintaining a
      table of authenticated nodes

   o  generating and updating a shared Domain Key for a set of CAP nodes

   o  accepting requests to generate and securely deliver shared link
      keys to individual pairs of CAP nodes that wish to communicate
      securely

   To avoid transmitting key material in the clear, a node that is
   intended to join a Security Domain MUST be preconfigured with one or
   more shared keys relevant to the Security Domain.

   In Standard Security Mode, the node MAY be preconfigured with the
   Domain Key, which allows the node to communicate securely with other
   CAP nodes sharing the same key, but does not provide any per-node
   authentication.  Or, the node MAY be preconfigured with a Link Key
   shared between itself and the Trust Center.  This key is used to
   securely join the domain and request the Domain Key. As long as the
   node has one of these keys, it can make use of the Trust Center to
   establish node-to-node Link Keys in order to secure particular
   pairwise communications.

   In High Security Mode, the node MAY be preconfigured with a Master
   Key shared between itself and the Trust Center.  This Master Key is
   then used to mutually establish a Link Key according to the SKKE
   mechanisms described in Section 4.4.2.6 of the ZigBee Specification.
   The Trust Center MAY then generate and deliver Master Keys to pairs
   of CAP nodes, and those nodes may also make use of SKKE to mutually
   establish Link Keys.

   To support a scenario in which pre-shared keys are not feasible,
   other key exchange mechanisms outside of CAP MAY be employed to



Tolle                    Expires April 11, 2009                [Page 24]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   securely agree on shared keys over the network.  The shared keys may
   then be employed as ZigBee Link Keys or Master Keys to secure future
   communications.

8.2.1.  Key Management Protocol Examples

   This section gives examples of the proper usage of the ZigBee
   security services in the end-to-end UDP/IP context used by CAP nodes.
   In general, the behaviors defined in Section 4.6 are used, but
   modified so that the Data Peer is directly interacting with the Trust
   Center, instead of relying on its ZigBee Network Layer parent to
   perform the authentication.  For protocol exchanges that do not rely
   on the ZigBee Network Layer, such as Update_Key, then no modification
   is required.

   Join Domain with Preconfigured Domain Key

   Trust                                                        Joining
   Center                                                      Data Peer
     |                                                            |
     | Domain_kt[ Update_Device( 00 {Standard,Secured,Rejoin} ) ] |
     | <==========================================================|
     |                                                            |
     | Domain_kt[ Transport_Key( 01 Std Domain, Key=0, Seq=0 ) ]  |
     |==========================================================> |
     |                                                            |
     |                                                            |

   When a new device is preconfigured with the correct Domain Key and
   Domain Key Sequence Number, it MAY send a message secured with that
   key in order to inform the Trust Center of its presence in the
   network.

   Join Domain with Preconfigured Trust Center Link Key

   Trust                                                        Joining
   Center                                                      Data Peer
     |                                                            |
     |  TC_Link_kt[ Update_Device( 00 {Standard, Sec, Rejoin} ) ] |
     | <==========================================================|
     |                                                            |
     | TC_Link_kt[ Transport_Key( 01 Std Domain, Key=k, Seq=s ) ] |
     |==========================================================> |
     |                                                            |
     |                                                            |

   When a new device is preconfigured with a Link Key that has been
   shared with the Trust Center, it MAY send a message secured with that



Tolle                    Expires April 11, 2009                [Page 25]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   key in order to inform the Trust Center of its presence and then
   receive the current Domain Key.

   Request the Active Domain Key

   Trust                                                        Joined
   Center                                                      Data Peer
     |                                                            |
     |           TC_Link_kt[ Request_Key( 01 Domain ) ]           |
     | <==========================================================|
     |                                                            |
     | TC_Link_kt[ Transport_Key( 01 Std Domain, Key=k, Seq=s ) ] |
     |==========================================================> |
     |                                                            |
     |                                                            |

   A new device may request the current Domain Key at any time, using an
   interaction secured by a shared Link Key with the Trust Center.

   Distribute a new Domain Key

   Trust                                                        Joined
   Center                                                     Data Peer
     |                                                            |
     | kt [ Transport_Key( 01 Std Domain, Key=k', Seq=s+1 ) ]     |
     |==========================================================> |
     |
     |                                                          Store
     |                                                        Alternate
     |                                                           Key
     |
     |            kt [ Switch_Key( Seq=s+1 ) ]                    |
     |==========================================================> |
     |
     |                                                           Use
     |                                                           New
     |                                                           Key
     |
     |                                                            |
     |                                                            |

   The Trust Center MAY distribute a new Domain Key to each node in its
   registered list using unicast UDP/IP messages.  If IP multicast is
   available, then the Trust Center MAY also distribute the new Domain
   Key using multicast.  If delivered via unicast, the message MUST be
   secured with the specific Link Key shared with each receiving node.
   If delivered via multicast, the message MUST be secured with the
   shared Domain Key. This key is then held by the nodes until they



Tolle                    Expires April 11, 2009                [Page 26]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   receive a Switch Key message secured according to the rules above, at
   which time the new key is activated.  When activating the new key,
   the node resets the incoming frame counters and outgoing frame
   counter to 0.  If the node is not capable of holding two keys at the
   same time, then the new key MAY be activated immediately without
   waiting for the Switch Key message.

   Distribute a new Trust Center Link or Master Key

   Trust                                                        Joined
   Center                                                     Data Peer
     |                                                            |
     |    TC_Link_kt [ Transport_Key( 04 TC Link, Key=k' ) ]      |
     |==========================================================> |
     |

   The Trust Center MAY send a new Link Key or Master Key to a CAP node
   using the Transport Key message.  Upon reception, the CAP node MUST
   replace the Trust Center's entry in the apsDeviceKeyPairSet table.

   Request Node-To-Node Application Link Keys


   Data Peer                      Trust                        Data Peer
   Initiator                      Center                       Responder
     |                              |                              |
     | [ Request_Key( 02 App,       |                              |
     |         Responder Addr ) ]   |                              |
     |============================> |                              |
     |                              |                              |
     |   [ Transport_Key(           |                              |
     |      03 App Link Key,        |  [ Transport_Key(            |
     |      Key=k, Ptnr=Responder,  |     03 App Link Key,         |
     |      Initiator=1 ) ]         |     Key=k, Ptnr=Initiator,   |
     | <============================|     Initiator=0 ) ]          |
     |                              |=============================>|
     |                              |                              |
                                    |
   Store                            |                            Store
    Key                             |                             Key
                                    |
     |                              |                              |
     |                                                             |
     |          Initiator-Responder_Link[ ZCL Operation ]          |
     |===========================================================> |
     |                              |                              |
     |                              |                              |




Tolle                    Expires April 11, 2009                [Page 27]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   A node that wishes to initiate secure communication with another node
   sharing the same Trust Center may request that the Trust Center
   generate a shared Link Key for the pair of nodes.  The Key k that
   gets sent to the nodes MUST be randomly generated.  When the nodes
   receive the key, they MUST add it to the peer node's entry in the
   apsDeviceKeyPairSet table.  These messages MUST be secured by the
   Trust Center's Link Key for the receiving node.  In High-Security
   Mode, the Trust Center MAY distribute a shared Master Key as well.

   Leaving the Domain

   Trust                                                        Leaving
   Center                                                      Data Peer
     |                                                            |
     |              Update_Device( 02 Device Left )               |
     | <==========================================================|
     |                                                            |

   A device MAY inform the Trust Center that it is unregistering for
   Domain Key updates and Link Key delivery by sending an Update Device
   message with the above status code.

   Telling a Device to Leave the Domain

   Trust                                                        Leaving
   Center                                                      Data Peer
     |                                                            |
     |                Remove_Device( Leaving Node )               |
     |==========================================================> |
     |                                                            |

   The Trust Center MAY also inform a device that it is no longer
   allowed within the Security Domain by sending it a Remove Device
   message.  The device will no longer receive Domain Key updates or
   Link Key deliveries after this message has been sent and the node's
   entry has been removed from the Trust Center's table.

8.2.2.  Key Management Protocol Messages

   Some of the APS messages used for key management are also adapted to
   support the IP addresses used by CAP.

   APS_CMD_SKKE_1 (0x01)  This message includes an Initiator Address and
      a Responder Address.  Each one is replaced with a CAP Address
      Record representing the appropriate node.






Tolle                    Expires April 11, 2009                [Page 28]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   APS_CMD_SKKE_2 (0x02)  This message includes an Initiator Address and
      a Responder Address.  Each one is replaced with a CAP Address
      Record representing the appropriate node.

   APS_CMD_SKKE_3 (0x03)  This message includes an Initiator Address and
      a Responder Address.  Each one is replaced with a CAP Address
      Record representing the appropriate node.

   APS_CMD_SKKE_4 (0x04)  This message includes an Initiator Address and
      a Responder Address.  Each one is replaced with a CAP Address
      Record representing the appropriate node.

   APS_CMD_TRANSPORT_KEY (0x05)  This message carries Key Descriptors.
      The message does not require modification, but the Key Descriptors
      themselves are modified because they include ZigBee EUI-64
      Addresses.  The modified Key Descriptors are below.  Note that the
      discussion about the UseParent and ParentAddress operation
      parameters only applies to ZigBee (when a routing parent
      authenticates on behalf of a joining device), and so those
      parameters can be ignored.

      Trust Center Master Key (0x00)  Replace the Destination and Source
         Addresses with CAP Address Records.

      Standard Domain Key (0x01)  Replace the Destination and Source
         Addresses with CAP Address Records.

      Application Master Key (0x02)  Replace the Partner Address with a
         CAP Address Record.

      Application Link Key (0x03)  Replace the Partner Address with a
         CAP Address Record.

      Trust Center Link Key (0x04)  Replace the Destination and Source
         Addresses with CAP Address Records.

      High-Security Domain Key (0x05)  Replace the Destination and
         Source Addresses with CAP Address Records.

   APS_CMD_UPDATE_DEVICE (0x06)  This message is sent to the Trust
      Center by a node that is joining the security domain.  It includes
      the two ZigBee Source Addresses (Device Address and Device short
      address).  These two fields are replaced with a single CAP address
      record representing the device sending the message.  The Status
      field remains unchanged.






Tolle                    Expires April 11, 2009                [Page 29]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   APS_CMD_REMOVE_DEVICE (0x07)  This message is used to tell a node to
      leave the security domain.  It contains the address of that node,
      which is replaced by a CAP Address Record.

   APS_CMD_REQUEST_KEY (0x08)  This message is used to request the
      active domain key from the Trust Center.  The message is also used
      to request that a pair of application link keys be delivered to a
      pair of nodes in the domain, so the nodes can communicate
      securely.  When the key being requested is an Application Link Key
      and the Partner Address is included, the Partner Address is
      replaced with a CAP Address Record.

   APS_CMD_SWITCH_KEY (0x09)  This message tells a node to start using a
      particular domain key.  It contains no addresses, and so it may be
      used as-is.

   APS_CMD_EA_INIT_CHLNG (0x0a)  This message includes an Initiator
      Address and a Responder Address.  Each one is replaced with a CAP
      Address Record representing the appropriate node.

   APS_CMD_EA_RSP_CHLNG (0x0b)  This message includes an Initiator
      Address and a Responder Address.  Each one is replaced with a CAP
      Address Record representing the appropriate node.

   APS_CMD_EA_INIT_MAC_DATA (0x0c)  This message does not contain any
      addresses, and is used without modification.

   APS_CMD_EA_RSP_MAC_DATA (0x0d)  This message does not contain any
      addresses, and is used without modification.

   APS_CMD_TUNNEL (0x0e)  This message contains a Destination Address,
      which is replaced by a CAP Address Record.


9.  Security Considerations

   CAP relies on UDP/IP for transport between nodes, which is insecure
   by default.  To remedy this, CAP adapts the ZigBee Application Layer
   Security system to provide authentication and encryption for CAP
   traffic between nodes.

   If network-layer security is available, such as IPsec [RFC2411], CAP
   peers may make use of it to protect their messages.

   As written, the APS Layer Security system relies on shared keys,
   which may become unwieldy in large deployments.  For this reason,
   alternate key-agreement mechanisms may be used to establish shared
   keys which are then used by CAP.



Tolle                    Expires April 11, 2009                [Page 30]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


   As written, the APS Layer Security system relies on the presence of a
   Trust Center to store and manage keys on behalf of the nodes in the
   network.  This Trust Center represents a single point of possible
   attack, and if this risk is unacceptable to the application designer,
   alternate key management mechanisms should be considered.


10.  IANA Considerations

   CAP requires a UDP port number to operate.  An application will be
   submitted for allocation of a well-known UDP port number to CAP.


11.  References

11.1.  Normative References

   [IEEE802154]
              IEEE Computer Society, "IEEE Std. 802.15.4-2003",
              October 2003.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

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

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2373]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 2373, July 1998.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC5342]  Eastlake. , D., "IANA Considerations and IETF Protocol
              Usage for IEEE 802 Parameters", BCP 141, RFC 5342,
              September 2008.

   [ZigBee]   ZigBee Alliance, "ZigBee Specification", January 2008.

   [ZigBeeCL]
              ZigBee Alliance, "ZigBee Cluster Library Specification",
              October 2007.






Tolle                    Expires April 11, 2009                [Page 31]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


11.2.  Informative References

   [DPWS]     Microsoft Corporation, "Devices Profile for Web Services",
              February 2006.

   [I-D.cheshire-dnsext-dns-sd]
              Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", draft-cheshire-dnsext-dns-sd-05 (work in
              progress), September 2008.

   [I-D.cheshire-dnsext-multicastdns]
              Cheshire, S. and M. Krochmal, "Multicast DNS",
              draft-cheshire-dnsext-multicastdns-07 (work in progress),
              September 2008.

   [RFC2411]  Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
              Document Roadmap", RFC 2411, November 1998.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

   [UPnP]     UPnP Forum, "UPnP Device Architecture 1.0", April 2008.

   [ZigBeeHA]
              ZigBee Alliance, "ZigBee Home Automation Public
              Application Profile", October 2007.

   [ZigBeeSE]
              ZigBee Alliance, "ZigBee Smart Energy Profile
              Specification", May 2008.


Author's Address

   Gilman Tolle
   Arch Rock Corporation
   501 2nd St. Ste 410
   San Francisco  94107
   US

   Phone: 415-692-0828
   Email: gtolle@archrock.com
   URI:   http://www.archrock.com







Tolle                    Expires April 11, 2009                [Page 32]

Internet-Draft  UDP/IP Adaptation of ZigBee App Protocol    October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Tolle                    Expires April 11, 2009                [Page 33]


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