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]