RFC 8323
CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
9. Securing CoAP
"Security Challenges For the Internet Of Things" [SecurityChallenges] recommends the following: ... it is essential that IoT protocol suites specify a mandatory to implement but optional to use security solution. This will ensure security is available in all implementations, but configurable to use when not necessary (e.g., in closed environment). ... even if those features stretch the capabilities of such devices. A security solution MUST be implemented to protect CoAP over reliable transports and MUST be enabled by default. This document defines the TLS binding, but alternative solutions at different layers in the protocol stack MAY be used to protect CoAP over reliable transports
when appropriate. Note that there is ongoing work to support a data- object-based security model for CoAP that is independent of transport (see [OSCORE]).9.1. TLS Binding for CoAP over TCP
The TLS usage guidance in [RFC7925] applies, including the guidance about cipher suites in that document that are derived from the mandatory-to-implement cipher suites defined in [RFC7252]. This guidance assumes implementation in a constrained device or for communication with a constrained device. However, CoAP over TCP/TLS has a wider applicability. It may, for example, be implemented on a gateway or on a device that is less constrained (such as a smart phone or a tablet), for communication with a peer that is likewise less constrained, or within a back-end environment that only communicates with constrained devices via proxies. As an exception to the previous paragraph, in this case, the recommendations in [RFC7525] are more appropriate. Since the guidance offered in [RFC7925] differs from the guidance offered in [RFC7525] in terms of algorithms and credential types, it is assumed that an implementation of CoAP over TCP/TLS that needs to support both cases implements the recommendations offered by both specifications. During the provisioning phase, a CoAP device is provided with the security information that it needs, including keying materials, access control lists, and authorization servers. At the end of the provisioning phase, the device will be in one of four security modes: NoSec: TLS is disabled. PreSharedKey: TLS is enabled. The guidance in Section 4.2 of [RFC7925] applies. RawPublicKey: TLS is enabled. The guidance in Section 4.3 of [RFC7925] applies. Certificate: TLS is enabled. The guidance in Section 4.4 of [RFC7925] applies. The "NoSec" mode is optional to implement. The system simply sends the packets over normal TCP; this is indicated by the "coap+tcp" scheme and the TCP CoAP default port. The system is secured only by keeping attackers from being able to send or receive packets from the network with the CoAP nodes.
"PreSharedKey", "RawPublicKey", or "Certificate" is mandatory to implement for the TLS binding, depending on the credential type used with the device. These security modes are achieved using TLS and are indicated by the "coaps+tcp" scheme and TLS-secured CoAP default port.9.2. TLS Usage for CoAP over WebSockets
A CoAP client requesting a resource identified by a "coaps+ws" URI negotiates a secure WebSocket connection to a WebSocket server endpoint with a "wss" URI. This is described in Section 8.4. The client MUST perform a TLS handshake after opening the connection to the server. The guidance in Section 4.1 of [RFC6455] applies. When a CoAP server exposes resources identified by a "coaps+ws" URI, the guidance in Section 4.4 of [RFC7925] applies towards mandatory- to-implement TLS functionality for certificates. For the server-side requirements for accepting incoming connections over an HTTPS (HTTP over TLS) port, the guidance in Section 4.2 of [RFC6455] applies. Note that the guidance above formally inherits the mandatory-to- implement cipher suites defined in [RFC5246]. However, modern browsers usually implement cipher suites that are more recent; these cipher suites are then automatically picked up via the JavaScript WebSocket API. WebSocket servers that provide secure CoAP over WebSockets for the browser use case will need to follow the browser preferences and MUST follow [RFC7525].10. Security Considerations
The security considerations of [RFC7252] apply. For CoAP over WebSockets and CoAP over TLS-secured WebSockets, the security considerations of [RFC6455] also apply.10.1. Signaling Messages
The guidance given by an Alternative-Address Option cannot be followed blindly. In particular, a peer MUST NOT assume that a successful connection to the Alternative-Address inherits all the security properties of the current connection.
11. IANA Considerations
11.1. Signaling Codes
IANA has created a third subregistry for values of the Code field in the CoAP header (Section 12.1 of [RFC7252]). The name of this subregistry is "CoAP Signaling Codes". Each entry in the subregistry must include the Signaling Code in the range 7.00-7.31, its name, and a reference to its documentation. Initial entries in this subregistry are as follows: +------+---------+-----------+ | Code | Name | Reference | +------+---------+-----------+ | 7.01 | CSM | RFC 8323 | | | | | | 7.02 | Ping | RFC 8323 | | | | | | 7.03 | Pong | RFC 8323 | | | | | | 7.04 | Release | RFC 8323 | | | | | | 7.05 | Abort | RFC 8323 | +------+---------+-----------+ Table 1: CoAP Signaling Codes All other Signaling Codes are Unassigned. The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [RFC8126].11.2. CoAP Signaling Option Numbers Registry
IANA has created a subregistry for Option Numbers used in CoAP Signaling Options within the "Constrained RESTful Environments (CoRE) Parameters" registry. The name of this subregistry is "CoAP Signaling Option Numbers". Each entry in the subregistry must include one or more of the codes in the "CoAP Signaling Codes" subregistry (Section 11.1), the number for the Option, the name of the Option, and a reference to the Option's documentation.
Initial entries in this subregistry are as follows: +------------+--------+---------------------+-----------+ | Applies to | Number | Name | Reference | +------------+--------+---------------------+-----------+ | 7.01 | 2 | Max-Message-Size | RFC 8323 | | | | | | | 7.01 | 4 | Block-Wise-Transfer | RFC 8323 | | | | | | | 7.02, 7.03 | 2 | Custody | RFC 8323 | | | | | | | 7.04 | 2 | Alternative-Address | RFC 8323 | | | | | | | 7.04 | 4 | Hold-Off | RFC 8323 | | | | | | | 7.05 | 2 | Bad-CSM-Option | RFC 8323 | +------------+--------+---------------------+-----------+ Table 2: CoAP Signaling Option Codes The IANA policy for future additions to this subregistry is based on number ranges for the option numbers, analogous to the policy defined in Section 12.2 of [RFC7252]. (The policy is analogous rather than identical because the structure of this subregistry includes an additional column ("Applies to"); however, the value of this column has no influence on the policy.) The documentation for a Signaling Option Number should specify the semantics of an option with that number, including the following properties: o Whether the option is critical or elective, as determined by the Option Number. o Whether the option is repeatable. o The format and length of the option's value. o The base value for the option, if any.
11.3. Service Name and Port Number Registration
IANA has assigned the port number 5683 and the service name "coap", in accordance with [RFC6335]. Service Name: coap Transport Protocol: tcp Assignee: IESG <iesg@ietf.org> Contact: IETF Chair <chair@ietf.org> Description: Constrained Application Protocol (CoAP) Reference: RFC 8323 Port Number: 568311.4. Secure Service Name and Port Number Registration
IANA has assigned the port number 5684 and the service name "coaps", in accordance with [RFC6335]. The port number is to address the exceptional case of TLS implementations that do not support the ALPN extension [RFC7301]. Service Name: coaps Transport Protocol: tcp Assignee: IESG <iesg@ietf.org> Contact: IETF Chair <chair@ietf.org> Description: Constrained Application Protocol (CoAP)
Reference:
[RFC7301], RFC 8323
Port Number:
5684
11.5. URI Scheme Registration
URI schemes are registered within the "Uniform Resource Identifier
(URI) Schemes" registry maintained at [IANA.uri-schemes].
Note: The following has been added as a note for each of the URI
schemes defined in this document:
CoAP registers different URI schemes for accessing CoAP resources
via different protocols. This approach runs counter to the WWW
principle that a URI identifies a resource and that multiple URIs
for identifying the same resource should be avoided
<https://www.w3.org/TR/webarch/#avoid-uri-aliases>.
This is not a problem for many of the usage scenarios envisioned for
CoAP over reliable transports; additional URI schemes can be
introduced to address additional usage scenarios (as being prepared,
for example, in [Multi-Transport-URIs] and [CoAP-Alt-Transports]).
11.5.1. coap+tcp
IANA has registered the URI scheme "coap+tcp". This registration
request complies with [RFC7595].
Scheme name:
coap+tcp
Status:
Permanent
Applications/protocols that use this scheme name:
The scheme is used by CoAP endpoints to access CoAP resources
using TCP.
Contact:
IETF Chair <chair@ietf.org>
Change controller:
IESG <iesg@ietf.org>
Reference:
Section 8.1 in RFC 8323
11.5.2. coaps+tcp
IANA has registered the URI scheme "coaps+tcp". This registration request complies with [RFC7595]. Scheme name: coaps+tcp Status: Permanent Applications/protocols that use this scheme name: The scheme is used by CoAP endpoints to access CoAP resources using TLS. Contact: IETF Chair <chair@ietf.org> Change controller: IESG <iesg@ietf.org> Reference: Section 8.2 in RFC 832311.5.3. coap+ws
IANA has registered the URI scheme "coap+ws". This registration request complies with [RFC7595]. Scheme name: coap+ws Status: Permanent Applications/protocols that use this scheme name: The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket Protocol. Contact: IETF Chair <chair@ietf.org> Change controller: IESG <iesg@ietf.org> Reference: Section 8.3 in RFC 8323
11.5.4. coaps+ws
IANA has registered the URI scheme "coaps+ws". This registration request complies with [RFC7595]. Scheme name: coaps+ws Status: Permanent Applications/protocols that use this scheme name: The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket Protocol secured with TLS. Contact: IETF Chair <chair@ietf.org> Change controller: IESG <iesg@ietf.org> References: Section 8.4 in RFC 832311.6. Well-Known URI Suffix Registration
IANA has registered "coap" in the "Well-Known URIs" registry. This registration request complies with [RFC5785]. URI suffix: coap Change controller: IETF Specification document(s): RFC 8323 Related information: None.
11.7. ALPN Protocol Identifier
IANA has assigned the following value in the "Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry created by [RFC7301]. The "coap" string identifies CoAP when used over TLS. Protocol: CoAP Identification Sequence: 0x63 0x6f 0x61 0x70 ("coap") Reference: RFC 832311.8. WebSocket Subprotocol Registration
IANA has registered the WebSocket CoAP subprotocol in the "WebSocket Subprotocol Name Registry": Subprotocol Identifier: coap Subprotocol Common Name: Constrained Application Protocol (CoAP) Subprotocol Definition: RFC 832311.9. CoAP Option Numbers Registry
IANA has added this document as a reference for the following entries registered by [RFC7959] in the "CoAP Option Numbers" subregistry defined by [RFC7252]: +--------+--------+--------------------+ | Number | Name | Reference | +--------+--------+--------------------+ | 23 | Block2 | RFC 7959, RFC 8323 | | | | | | 27 | Block1 | RFC 7959, RFC 8323 | +--------+--------+--------------------+ Table 3: CoAP Option Numbers
12. References
12.1. Normative References
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>. [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>. [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <https://www.rfc-editor.org/info/rfc5785>. [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>. [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, <https://www.rfc-editor.org/info/rfc6455>. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>. [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>. [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <https://www.rfc-editor.org/info/rfc7595>. [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-editor.org/info/rfc7641>. [RFC7925] Tschofenig, H., Ed., and T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, July 2016, <https://www.rfc-editor.org/info/rfc7925>. [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/info/rfc7959>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8307] Bormann, C., "Well-Known URIs for the WebSocket Protocol", RFC 8307, DOI 10.17487/RFC8307, January 2018, <https://www.rfc-editor.org/info/rfc8307>.
12.2. Informative References
[BK2015] Byrne, C. and J. Kleberg, "Advisory Guidelines for UDP Deployment", Work in Progress, draft-byrne-opsec-udp- advisory-00, July 2015. [CoAP-Alt-Transports] Silverajan, B. and T. Savolainen, "CoAP Communication with Alternative Transports", Work in Progress, draft-silverajan-core-coap-alternative-transports-10, July 2017. [CoCoA] Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, "CoAP Simple Congestion Control/Advanced", Work in Progress, draft-ietf-core-cocoa-02, October 2017. [EK2016] Edeline, K., Kuehlewind, M., Trammell, B., Aben, E., and B. Donnet, "Using UDP for Internet Transport Evolution", arXiv preprint 1612.07816, December 2016, <https://arxiv.org/abs/1612.07816>. [HomeGateway] Haetoenen, S., Nyrhinen, A., Eggert, L., Strowes, S., Sarolahti, P., and N. Kojo, "An experimental study of home gateway characteristics", Proceedings of the 10th ACM SIGCOMM conference on Internet measurement, DOI 10.1145/1879141.1879174, November 2010. [IANA.uri-schemes] IANA, "Uniform Resource Identifier (URI) Schemes", <https://www.iana.org/assignments/uri-schemes>. [LWM2M] Open Mobile Alliance, "Lightweight Machine to Machine Technical Specification Version 1.0", February 2017, <http://www.openmobilealliance.org/release/LightweightM2M/ V1_0-20170208-A/ OMA-TS-LightweightM2M-V1_0-20170208-A.pdf>. [Multi-Transport-URIs] Thaler, D., "Using URIs With Multiple Transport Stacks", Work in Progress, draft-thaler-appsawg-multi-transport- uris-01, July 2017. [OSCORE] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", Work in Progress, draft-ietf-core-object- security-08, January 2018.
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>. [RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>. [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>. [SecurityChallenges] Polk, T. and S. Turner, "Security Challenges For the Internet Of Things", Interconnecting Smart Objects with the Internet / IAB Workshop, February 2011, <https://www.iab.org/wp-content/IAB-uploads/2011/03/ Turner.pdf>. [SW2016] Swett, I., "QUIC Deployment Experience @Google", IETF 96 Proceedings, Berlin, Germany, July 2016, <https://www.ietf.org/proceedings/96/slides/ slides-96-quic-3.pdf>. [TCP-in-IoT] Gomez, C., Crowcroft, J., and M. Scharf, "TCP Usage Guidance in the Internet of Things (IoT)", Work in Progress, draft-ietf-lwig-tcp-constrained-node- networks-01, October 2017.
Appendix A. Examples of CoAP over WebSockets
This appendix gives examples for the first two configurations discussed in Section 4. An example of the process followed by a CoAP client to retrieve the representation of a resource identified by a "coap+ws" URI might be as follows. Figure 17 below illustrates the WebSocket and CoAP messages exchanged in detail. 1. The CoAP client obtains the URI <coap+ws://example.org/sensors/temperature?u=Cel>, for example, from a resource representation that it retrieved previously. 2. The CoAP client establishes a WebSocket connection to the endpoint URI composed of the authority "example.org" and the well-known path "/.well-known/coap", <ws://example.org/.well-known/coap>. 3. CSMs (Section 5.3) are exchanged (not shown). 4. The CoAP client sends a single-frame, masked, binary message containing a CoAP request. The request indicates the target resource with the Uri-Path ("sensors", "temperature") and Uri-Query ("u=Cel") Options. 5. The CoAP client waits for the server to return a response. 6. The CoAP client uses the connection for further requests, or the connection is closed.
CoAP CoAP Client Server (WebSocket (WebSocket Client) Server) | | | | +=========>| GET /.well-known/coap HTTP/1.1 | | Host: example.org | | Upgrade: websocket | | Connection: Upgrade | | Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== | | Sec-WebSocket-Protocol: coap | | Sec-WebSocket-Version: 13 | | |<=========+ HTTP/1.1 101 Switching Protocols | | Upgrade: websocket | | Connection: Upgrade | | Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= | | Sec-WebSocket-Protocol: coap : : :<-------->: Exchange of CSMs (not shown) | | +--------->| Binary frame (opcode=%x2, FIN=1, MASK=1) | | +-------------------------+ | | | GET | | | | Token: 0x53 | | | | Uri-Path: "sensors" | | | | Uri-Path: "temperature" | | | | Uri-Query: "u=Cel" | | | +-------------------------+ | | |<---------+ Binary frame (opcode=%x2, FIN=1, MASK=0) | | +-------------------------+ | | | 2.05 Content | | | | Token: 0x53 | | | | Payload: "22.3 Cel" | | | +-------------------------+ : : : : +--------->| Close frame (opcode=%x8, FIN=1, MASK=1) | | |<---------+ Close frame (opcode=%x8, FIN=1, MASK=0) | | Figure 17: A CoAP Client Retrieves the Representation of a Resource Identified by a "coap+ws" URI
Figure 18 shows how a CoAP client uses a CoAP forward proxy with a WebSocket endpoint to retrieve the representation of the resource "coap://[2001:db8::1]/". The use of the forward proxy and the address of the WebSocket endpoint are determined by the client from local configuration rules. The request URI is specified in the Proxy-Uri Option. Since the request URI uses the "coap" URI scheme, the proxy fulfills the request by issuing a Confirmable GET request over UDP to the CoAP server and returning the response over the WebSocket connection to the client. CoAP CoAP CoAP Client Proxy Server (WebSocket (WebSocket (UDP Client) Server) Endpoint) | | | +--------->| | Binary frame (opcode=%x2, FIN=1, MASK=1) | | | +------------------------------------+ | | | | GET | | | | | Token: 0x7d | | | | | Proxy-Uri: "coap://[2001:db8::1]/" | | | | +------------------------------------+ | | | | +--------->| CoAP message (Ver=1, T=Con, MID=0x8f54) | | | +------------------------------------+ | | | | GET | | | | | Token: 0x0a15 | | | | +------------------------------------+ | | | | |<---------+ CoAP message (Ver=1, T=Ack, MID=0x8f54) | | | +------------------------------------+ | | | | 2.05 Content | | | | | Token: 0x0a15 | | | | | Payload: "ready" | | | | +------------------------------------+ | | | |<---------+ | Binary frame (opcode=%x2, FIN=1, MASK=0) | | | +------------------------------------+ | | | | 2.05 Content | | | | | Token: 0x7d | | | | | Payload: "ready" | | | | +------------------------------------+ | | | Figure 18: A CoAP Client Retrieves the Representation of a Resource Identified by a "coap" URI via a WebSocket-Enabled CoAP Proxy
Acknowledgments
We would like to thank Stephen Berard, Geoffrey Cristallo, Olivier Delaby, Esko Dijk, Christian Groves, Nadir Javed, Michael Koster, Achim Kraus, David Navarro, Szymon Sasin, Goeran Selander, Zach Shelby, Andrew Summers, Julien Vermillard, and Gengyu Wei for their feedback. Last Call reviews from Yoshifumi Nishida, Mark Nottingham, and Meral Shirazipour as well as several IESG reviewers provided extensive comments; from the IESG, we would like to specifically call out Ben Campbell, Mirja Kuehlewind, Eric Rescorla, Adam Roach, and the responsible AD Alexey Melnikov.Contributors
Matthias Kovatsch Siemens AG Otto-Hahn-Ring 6 Munich D-81739 Germany Phone: +49-173-5288856 Email: matthias.kovatsch@siemens.com Teemu Savolainen Nokia Technologies Hatanpaan valtatie 30 Tampere FI-33100 Finland Email: teemu.savolainen@nokia.com Valik Solorzano Barboza Zebra Technologies 820 W. Jackson Blvd. Suite 700 Chicago, IL 60607 United States of America Phone: +1-847-634-6700 Email: vsolorzanobarboza@zebra.com
Authors' Addresses
Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Simon Lemay Zebra Technologies 820 W. Jackson Blvd. Suite 700 Chicago, IL 60607 United States of America Phone: +1-847-634-6700 Email: slemay@zebra.com Hannes Tschofenig ARM Ltd. 110 Fulbourn Road Cambridge CB1 9NJ United Kingdom Email: Hannes.tschofenig@gmx.net URI: http://www.tschofenig.priv.at Klaus Hartke Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63905 Email: hartke@tzi.org
Bilhanan Silverajan Tampere University of Technology Korkeakoulunkatu 10 Tampere FI-33720 Finland Email: bilhanan.silverajan@tut.fi Brian Raymor (editor) Email: brianraymor@hotmail.com