Skip to content

Latest commit

 

History

History
154 lines (122 loc) · 5.55 KB

draft-wood-icnrg-ccnxoverudp.mkd

File metadata and controls

154 lines (122 loc) · 5.55 KB

title: CCNx over UDP abbrev: CCNx-over-UDP docname: draft-wood-icnrg-ccnxoverudp date: 2015-10-24 category: info

ipr: trust200902 area: General workgroup: ICNRG Working Group keyword: Internet-Draft

stand_alone: yes pi: [toc, sortrefs, symrefs]

author:

ins: I. Solis
name: Ignacio Solis
organization: PARC
email: [email protected]

normative: RFC2119: RFC6520: RFC6347: RFC0768: LINKLOCAL: target: https://github.com/PARC/ccnx-link-local-resources-rfc title: CCNx Link Local Resources author: - name: I. Solis ins: PARC, Inc. - name: C. Wood ins: PARC, Inc. date: 2015-10-24

--- abstract

This document describes how two nodes can create and run the CCNx protocol over UDP link. DTLS is required to encrypt all traffic between two nodes.

--- middle

Introduction

To enable interoperability between CCNx forwarder implementations over UDP {{RFC0768}}, one can create virtual links between endpoints to exchange CCNx messages (see {{basic-link}}).

+--+  (Virtual link)   +--+
|F1+-------------------+F2|
+--+                   +--+

{: #basic-link title="A virtual link between two CCNx-compliant forwarders F1 and F2."}

The goal of this document is to prescribe exactly how to transport CCNx messages between two CCNx-compliant forwarders over UDP {{RFC0768}} instead of directly over layer-2 Ethernet. Virtual links created over UDP must be secured by DTLS {{RFC6347}}. By default, DTLS provides (P)MTU size and fragmentation. Extensions enable keep-alive messages to be integrated {{RFC6520}}, but this is not a default feature. Consequently, the solution for running CCNx over UDP (DTLS) is to add keep-alive messages using link local names.

Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 {{RFC2119}}.

The following terms are used in this document.

Link local name: a name that is used in Interest messages that are only meant to traverse a single hop between two forwarders over a link.

Transport Assumptions and Requirements

We make the following assumptions about UDP as transport protocol.

  • UDP is an unreliable datagram service (i.e., best-effort datagram delivery).
  • Maximum MTU size of 4KB
  • UDP (via DTLS) or IP fragmentation subsumes CCNx fragmentation (which would be required for communication over layer-2 services.

Moreover, running CCNx over UDP between two forwarders requires DTLS to be implemented at both forwarders. CCNx messages will not traverse unsecured links between nodes.

Specification

This section outlines the information necessary for an implementation of the CCNx protocol to connect and communicate with a CCNx-compliant forwarder over UDP. The technique is simple: CCNx messages are encapsulated in the payload of (DTLS-protected) UDP packets, as shown below.

+----+-----+--------------------------------------+
| IP | UDP | DTLS |      CCNx Packet              |
+----+--------------------------------------------+
                  \_____________||________________/
                                \/
                 +---------------------------------+
                 | Headers |  Message | Validation |
                 +---------------------------------+

{: #packet-encap title="CCNx message encapsulation in UDP packets."}

Upon successful receipt of a UDP packet from one forwarder to another, a virtual link will have been established. This link is uniquely defined by the four-element tuple (SrcAddress, DstAddress, SrcPort, DstPort). Constructing virtual or overlay links that are multiplexed onto a single UDP link is not supported. The default UDP port for both the source and destination are 9596.

Options

Running CCNx over UDP with DTLS enabled solves many problems that would have to be directly addressed, including MTU size discovery or agreement and fragmentation. CCNx forwarders rely on DTLS to provide these two features.

Keep-alive messages are only supported in DTLS if the extension in {{RFC6520}} is implemented. Since this is not a standard feature of DTLS, CCNx forwarders must use their own keep-alive mechanism. CCNx forwarders will use the heartbeat resource specified in {{LINKLOCAL}} to periodically issue keep-alive messages at a rate of 1 message per second. Such a keep-alive message will be a CCNx Interest with the name

lci:/link/local/<identifier>/heartbeat/GET

where identifier is a random 32-bit identifier that the sender generates and associates with the target link. The response to this Interest is a Content Object with an empty payload, which serves as an acknowledgement of its receipt.

To avoid conflict, both forwarders must periodically send keep-alive messages at the same tunable rate (1 message per second). A peer forwarder will be considered unavailable if no keep-alive message is sent from the peer in 5 seconds. When a peer is determined to be unavailable by a forwarder, the link to said peer will be destroyed and its resources will be freed. Moreover, the DTLS session will be torn down. Both peers must re-initialize a DTLS session if they are to continue using the link.

Security Considerations

All UDP links are secured via DTLS. Issues of peer authentication and trust management in the DTLS protocol are outside the scope of this document.

--- back