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

Versions: 00 01 02 03 04 05 draft-ietf-core-coap-tcp-tls

CORE                                                            S. Lemay
Internet-Draft                                      V. Solorzano Barboza
Intended status: Standards Track                      Zebra Technologies
Expires: March 8, 2015                                H. Tschofenig, Ed.
                                                                ARM Ltd.
                                                       September 4, 2014


A TCP and TLS Transport for the Constrained Application Protocol (CoAP)
               draft-tschofenig-core-coap-tcp-tls-01.txt

Abstract

   The Hypertext Transfer Protocol (HTTP) has been designed with TCP as
   an underlying transport protocol.  The Constrained Application
   Protocol (CoAP), which has been inspired by HTTP, has on the other
   hand been defined to make use of UDP.  Reliable delivery, a simple
   congestion control mechanism, and flow control had been added to the
   CoAP protocol.  UDP is a good choice for networks that do not perform
   any form of filtering and firewalling.  There are, however, many
   deployment environments where UDP is either firewalled or subject to
   deep packet inspection.  These environments make the use of CoAP
   brittle.

   This document defines the use of CoAP over TCP as well as CoAP over
   TLS.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 8, 2015.








Lemay, et al.             Expires March 8, 2015                 [Page 1]


Internet-Draft         TCP/TLS Transport for CoAP         September 2014


Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Shim Header . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Developer Considerations  . . . . . . . . . . . . . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   The Internet protocol stack is organized in layers, namely data link
   layer, network layer, transport layer, and the application layer.

   IP emerged as the waist of the hour glass and supports a variety of
   link layers and new link layer technologies can be added in the
   future, without affecting IP.

   Combined with the end-to-end principle the hour glass indicates the
   level of protocol understanding intermediaries need to have in order
   to exchange forward IP packets between a sender and a receiver
   (absent any specific application layer entities, like proxies or
   caches).  Having IP as the waist meant that anyone could extend the
   layers above the network layer in the way they wanted to communicate
   end-to-end, including defining new transport layer protocols (as it
   was done with SCTP, and DCCP).

   Unfortunately, deployments departed from this ideal architecture.
   When the Constrained Application Protocol (CoAP) [RFC7252] was
   designed it was assumed that many Internet of Things deployments



Lemay, et al.             Expires March 8, 2015                 [Page 2]


Internet-Draft         TCP/TLS Transport for CoAP         September 2014


   would be clean-slate.  Today, we know that some deployments have to
   integrate well with existing enterprise infrastructure, where the use
   of UDP-based protocols is not well-received and firewalling use is
   very common.

   To make IoT devices work smoothly in these demanding environments
   CoAP has to make use of a different transport protocol, namely TCP
   [RFC0793] and in some situations even TLS [RFC5246].  This document
   describes a shim header that conveys length information about the
   included payload.  Modifications to CoAP are intentially avoided
   (e.g, to introduce optimizations).

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Shim Header

   This specification defines a simple layer necessary to convey length
   information about the exchange payloads in a 32-bit length field
   indicating the number of bytes in the payload following that header.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Length                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                          Figure 1: Shim Header.

4.  Developer Considerations

   The use of CoAP over a transport protocol offering reliable
   transmission already offers functionality that could be offered by
   CoAP itself.  While a developer can re-use an already existing CoAP
   protocol stack, the use of TCP makes some CoAP features redundant.

   Section 4.2 of [RFC7252] discusses the ability to convey messages in
   CoAP reliably as a "confirmable message", which always generates a
   response.  It can be used without harm but does not add any value
   since all messages would be transmitted reliably already thanks to
   the features offered by TCP.  A developer writing an application that
   runs CoAP over TCP or CoAP over TLS needs to be mindful about the
   changed semantic of CoAP.  For example, the marking the message as



Lemay, et al.             Expires March 8, 2015                 [Page 3]


Internet-Draft         TCP/TLS Transport for CoAP         September 2014


   non-confirmable (see Section 4.3 of [RFC7252]) does not make the
   transmission unreliable but it instead saves the transmission of one
   CoAP message.

5.  Security Considerations

   This document defines how to convey CoAP over TCP and TLS.  It does
   not introduce new vulnerabilities beyond those described already in
   the CoAP specification.

   When CoAP is exchanged over TLS port 443 then the "TLS Application
   Layer Protocol Negotiation Extension" [I-D.ietf-tls-applayerprotoneg]
   MUST be used to allow demultiplexing at the server-side unless out-
   of-band information ensures that the client only interacts with a
   server that is able to demultiplex CoAP messages over port 443.  This
   would, for example, be true for many Internet of Things deployments
   where clients are pre-configured to only ever talk with specific
   servers.

   When CoAP over TLS is used then the use of the shim header that
   includes the length information is redundant since the TLS protocol
   headers already include length information.  As such, the length
   header MUST be omitted when CoAP is exchanged over TLS.

6.  IANA Considerations

   This document requests a value from the "Application Layer Protocol
   Negotiation (ALPN) Protocol IDs" created by
   [I-D.ietf-tls-applayerprotoneg]:

   Protocol:  CoAP

   Identification Sequence:  0x63 0x6f 0x61 0x70 ("coap")

   Specification:  This document.

7.  Acknowledgements

   We would like to thank Michael Koster, Zach Shelby, and Szymon Sasin
   for their feedback.

8.  Normative References

   [I-D.ietf-tls-applayerprotoneg]
              Friedl, S., Popov, A., Langley, A., and S. Emile,
              "Transport Layer Security (TLS) Application Layer Protocol
              Negotiation Extension", draft-ietf-tls-applayerprotoneg-05
              (work in progress), March 2014.



Lemay, et al.             Expires March 8, 2015                 [Page 4]


Internet-Draft         TCP/TLS Transport for CoAP         September 2014


   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

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

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252, June 2014.

Authors' Addresses

   Simon Lemay
   Zebra Technologies
   820 W. Jackson Blvd.suite 700
   Chicago  60607
   United States of America

   Phone: +1-847-634-6700
   Email: slemay@zebra.com


   Valik Solorzano Barboza
   Zebra Technologies
   820 W. Jackson Blvd. suite 700
   Chicago  60607
   United States of America

   Phone: +1-847-634-6700
   Email: vsolorzanobarboza@zebra.com


   Hannes Tschofenig  (editor)
   ARM Ltd.
   110 Fulbourn Rd
   Cambridge  CB1 9NJ
   Great Britain

   Email: Hannes.tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at









Lemay, et al.             Expires March 8, 2015                 [Page 5]


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