ICNRG M. Stapp Internet-Draft Cisco Systems, Inc. Intended status: Experimental January 8, 2015 Expires: July 12, 2015 NDN Message Format Proposal draft-stapp-icnrg-ndn-msgs-00 Abstract This memo defines an on-the-wire format for Named-data Networking (NDN) protocol messages. NDN packets begin with a fixed-size header. After the header, the remainder of the message is composed of type- length-value (TLV) tuples. The Type and Length fields use a compact, fixed-size encoding scheme. The TLVs for message attributes that are standardized are defined in a registry. Part of the TLV number-space is reserved for standardized attributes. Other parts of the number- space are set aside for experimental use. 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 July 12, 2015. Copyright Notice Copyright (c) 2015 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 Stapp Expires July 12, 2015 [Page 1] Internet-Draft NDN Message Format Proposal January 2015 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. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. NDN Packets and Messages . . . . . . . . . . . . . . . . . . 4 2.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Packet Header Options . . . . . . . . . . . . . . . . . . 7 2.3. NDN Names . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Vendor-specific TLVs . . . . . . . . . . . . . . . . . . 9 2.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Interest Packets . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Message Header . . . . . . . . . . . . . . . . . . . . . 10 3.2. TLV Section . . . . . . . . . . . . . . . . . . . . . . . 10 4. Data Packets . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Message Header . . . . . . . . . . . . . . . . . . . . . 11 4.2. TLV Section . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Data Signatures . . . . . . . . . . . . . . . . . . . . . 11 5. Nack Packets . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Packet Header . . . . . . . . . . . . . . . . . . . . . . 13 5.2. TLV Section . . . . . . . . . . . . . . . . . . . . . . . 13 6. NDN TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. NDN Name . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. ContentData . . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Certificate . . . . . . . . . . . . . . . . . . . . . . . 14 6.4. PublisherPublicKeyDigest . . . . . . . . . . . . . . . . 14 6.5. PublisherPublicKeyName . . . . . . . . . . . . . . . . . 14 6.6. ContentDigest . . . . . . . . . . . . . . . . . . . . . . 14 6.7. PublicKey . . . . . . . . . . . . . . . . . . . . . . . . 15 6.8. KeyName . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.9. Signature . . . . . . . . . . . . . . . . . . . . . . . . 15 6.10. SignatureBits . . . . . . . . . . . . . . . . . . . . . . 15 6.11. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 15 6.12. Witness . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.13. DigestAlgorithm . . . . . . . . . . . . . . . . . . . . . 16 6.14. ContentExpiration . . . . . . . . . . . . . . . . . . . . 16 6.15. CacheTTL . . . . . . . . . . . . . . . . . . . . . . . . 16 6.16. TLV Type Codes . . . . . . . . . . . . . . . . . . . . . 16 7. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Message Header Number Assignments . . . . . . . . . . . . 17 7.2. Flag Bit Assignments . . . . . . . . . . . . . . . . . . 17 7.3. Error Code Assignments . . . . . . . . . . . . . . . . . 17 Stapp Expires July 12, 2015 [Page 2] Internet-Draft NDN Message Format Proposal January 2015 7.4. TLV Number Ranges . . . . . . . . . . . . . . . . . . . . 17 8. The CCNx Scheme . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 12. Normative References . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction Named-data Networking (NDN) [TODO cite Van], one of a family of Information-centric Networking protocols, proposes the replacement of IP's endpoint-to-endpoint communication model with one centered around named objects. In NDN networks, a client issues an Interest packet which names an object. No destination address is present: the network routes the Interest based on the name it carries. When a device - a server, a cache engine, or a router with built-in storage - determines that it can satisfy the Interest, it replies with a Data packet containing a Content object, and a cryptographic signature. No source address is present in any message - the network maintains sufficient state to route a Data packet back to the client. This model gives an NDN network a number of attractive properties, and NDN approaches have attracted interest from the networking research community over the last couple of years. NDN researchers have proposed a wide range of infrastructure and network services. This memo attempts to describe a somewhat limited baseline that can form the basis for more complex and sophisticated services. The baseline is composed of the fundamental packet transport definition, a set of mandatory-to-implement TLVs, and a definition of the basic security mechanisms. The work required to process each NDN packet at each network node (router) differs significantly from IP datagram handling. Each NDN router must examine the variable-length name in order to make forwarding decisions. Each NDN router must maintain state in order to be able to correlate Data packets from 'upstream' with 'downstream' clients; other data in packets may also need to be processed in order to support this requirement. Some routers may verify the signatures on some or all Data messages, as a means of detecting spoofing attempts. Some routers may cache Content objects; the network infrastructure itself becomes capable of acting as a distributed cache for popular or valuable data. The obligation to be stateful offers routers the opportunity to take an active role in congestion control. For all of these reasons, an efficient, clear NDN message encoding is central to the success of the overall NDN architecture. Stapp Expires July 12, 2015 [Page 3] Internet-Draft NDN Message Format Proposal January 2015 An NDN packet begins with a small header area; the body of the message is mainly composed of TLV tuples. The Name TLV always appears first in the message, so it's easy to locate in any message. All TLVs contain a length field, so routers and applications can navigate through messages efficiently. The TLV type-code number- space is divided into several ranges: a range for standardized attributes, a range for vendor-specific use, and a range for experimental use. This is still very much a work-in-progress. There are plenty of TODOs, including: o I've tried to develop a minimal set of TLVs and behavior: have I left out something crucial to a baseline client? o Details of content signature computation and verification o I've avoided discussion of other control or hop-by-hop messages (if any), OAM, neighbor discovery/adjacency establishment, etc. 1.1. Requirements Language 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 RFC 2119 [RFC2119]. 2. NDN Packets and Messages At present, there are two NDN message types: the Interest message, and the Data message. On the wire, an NDN message is carried in an NDN packet, which includes a fixed-size packet header. There are three types of NDN packets: Interest packets, Data packets and Nack packets. Each packet type is discussed in detail below. All NDN packets share several properties: o Packets begin with a fixed-size header, including a protocol version, the header size, and the size of the entire message o Optional header type-length-value (TLV) tuples are available for information designed for hop-by-hop processing o After the packet header and header options, the message begins; the message is itself a TLV o The Name TLV always appears first within the message TLV o TLVs may contain sub-TLVs Stapp Expires July 12, 2015 [Page 4] Internet-Draft NDN Message Format Proposal January 2015 o Each TLV includes the length of the entire TLV, even if sub-TLVs are present The NDN Packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ver | pkt type | packet-size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hop lim | flags | error/resvd | hlen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: ver The protocol version. The current value is 1. pkt type The packet type. The current packet types are Interest (1), Content (2), Nack (3). packet-size The number of octets in the packet, encoded as a 16-bit integer in network byte-order. hop lim A hop limit field, available for loop detection. flags Header bitflags field. error/ Reserved field; used for error return code in reserved Nack packets. hlen The number of octets in the header area, including any header option TLVs. All NDN packets begin with a protocol version and a packet-type. A standards action is REQUIRED in order to increment the protocol version or to assign a new packet-type. Routers MUST discard packets with protocol versions they do not support. In general, we expect that nodes may be able to process packets with some small range of protocol versions. NDN nodes that do not understand how to process a packet based on its version must discard the packet. The NDN packet size is represented as a 16-bit integer in network byte-order. At this point in the evolution of the NDN protocol, this offers a reasonable range of sizes while allowing for a compact Stapp Expires July 12, 2015 [Page 5] Internet-Draft NDN Message Format Proposal January 2015 fixed-size representation. The packet-size field includes the size of the header and all of the packet TLVs. A one-octet hop-limit field is available for loop detection. Routers MUST decrement the value by one before forwarding a message, and MUST NOT forward a message whose hop limit has reached zero. The initial hop limit value is still a topic of active discussion. We expect that common-sense values like 64 or 128 will be recommended eventually. Other loop detection schemes (such a Nonce value) may be available through use of header options. The flags field contains single-bit flags for use during hop-by-hop processing. TODO - define flags here, or below with assigned numbers? The reserved field is used to carry an error or status code when an Interest packet is returned as a Nack packet. The field is reserved in other packet types at this time. The header-length field contains the size of the entire header area. This is essentially the offset of the Message TLV in the packet, since the Message TLV always begins immediately after the packet header area. The header-length permits use of variable-sized and optional header option TLVs for a variety of purposes. Header options are described below. 2.1. TLV Encoding We propose a simple NDN TLV encoding that uses 2 octets for Type code and 2 octets for TLV Length. The TLV Type number space and initial assignments are specified in Section 7.4. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Value . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stapp Expires July 12, 2015 [Page 6] Internet-Draft NDN Message Format Proposal January 2015 The TLV Length field contains the number of octets in the Value field. This implies that a Length of zero may be valid for some TLV Types. The specification of a TLV may include restrictions or validation rules for the TLV's Length field. DISCUSSION: We feel that this encoding offers a reasonable balance between efficiency and flexibility. More complicated variable-length schemes introduce additional validation and processing complexity, as well as canonicalization requirements. Are there use-cases where this simple encoding is inadequate? 2.2. Packet Header Options Header options offer information beyond that available in the fixed header area. The header option facility supports experimentation with various hop-by-hop processing extensions during this period of NDN evolution. Header options are encoded as TLVs. The header option type-codes use a dedicated number space, distinct from the TLVs in the message body. We propose several possible header option TLVs, for use with alternative loop-detection methods and for Quality-of-Service (QOS) marking. These seem to be viable candidates for experimentation with hop-by-hop processing. Nonce option example: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'Nonce' | 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stapp Expires July 12, 2015 [Page 7] Internet-Draft NDN Message Format Proposal January 2015 Diffserv option example: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'DSCP' | 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSCP bits | +-+-+-+-+-+-+-+-+ Flow-label option example: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'Flow' | 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.3. NDN Names Every NDN message, unsurprisingly, contains a Name TLV: the Name is required for processing at each NDN node. NDN Names can contain several types of information: o Information needed to route an Interest towards a publisher o Information about a specific object, such as a file name o A segment or 'chunk' number, used when a client retrieves part of a large data object o Other standardized data that may be used by client/host stacks, or during network processing. o Application-specific or session-specific data that is meaningful to applications running at the client and publisher. NDN Names contain sub-TLVs, which demarcate the boundaries between these various constituent components. Each 'label' in a publisher name and each element in a filename is represented as a NameComponent TLV, for example. The segment number is represented in a NameSegment Stapp Expires July 12, 2015 [Page 8] Internet-Draft NDN Message Format Proposal January 2015 TLV. By convention, the NameSegment appears last in the collection of Name sub-TLVs. DISCUSSION: Is it really necessary to continue to force all of the information in Interests into the Name? Wouldn't it be clearer to use the Name only for publisher/routing info, object name info, and segment/sequence number? An InterestData or InterestAppData TLV could hold any other data: session information, encrypted fields, application-specific parameters that are not used in forwarding or caching. There would be benefits there for the routers, who wouldn't need to process data in the "Name" that are entirely unrelated to the forwarding or cacheing functions. Currently, the routers incur processing cost for both Interest and Content messages when large Name fields are present. App session data wouldn't often be cacheable in any case: it would likely be encrypted with a session key. The Name would still need to be unique, but that could be accomplished with a single NameComponent containing ... a timestamp and a random number, or a (reasonably strong) hash value. 2.4. Vendor-specific TLVs A vendor or industry group can introduce its own NDN TLV space using the vendor-specific encapsulation TLV with type code NDN_TLV_VendorSpecific (Section 7.4). The VendorSpecific TLV MUST contain a vendor identifier in the NDN_TLV_VendorId (Section 7.4) TLV. Any other contents of the container TLV are determined by the organization identified. Typically these will be further TLVs - that's our recommendation - but that is not mandatory. The VendorId must be unique and controlled by the organization using this mechanism. Example VendorIds include an OID, or a DNS name. The VendorId TLV must occur first in the VendorSpecific contents: implementations have to be able to decode the identifier in order to determine whether they can proceed and decode the remainder of the TLV's data. 2.5. Examples TODO -- add a couple of encoding examples. 3. Interest Packets Stapp Expires July 12, 2015 [Page 9] Internet-Draft NDN Message Format Proposal January 2015 The NDN Interest packet is specified as: INTEREST-PACKET := PACKET-HEADER INTEREST-TLV NAME-TLV [ NDN-TLV ... ] PACKET-HEADER := Common packet header area defined above, with packet-type == Interest INTEREST-TLV := NDN-TLV with Type == InterestMessage NAME-TLV := NDN-TLV with Type == Name 3.1. Message Header TODO -- brief overview; describe any special header options 3.2. TLV Section The Name TLV is always the first TLV inside the message TLV; this allows network nodes to find the Name easily. Another TLV that is processed at network nodes is the InterestLifetime. Note that we have specified the units used in the InterestLifetime as milliseconds. Nodes should validate any InterestLifetime value presented by a client: we'd expect that routers would have maximum and minimum lifetime values that would bound the lifetime values in Interest messages. DISCUSSION: We propose an Interest message simpler than the CCNx 0.x scheme. The selectors such as Min- and MaxSuffixComponents, Exclude bloom filter, ChildSelector, etc. are all ... excluded. Routers perform prefix-based matching on Names as they examine their FIBs, and exact-match in their PITs and CSes. Applications that want to offer complex query syntax or filtering need to use application- specific data for those purposes. See Section 2.3 for some discussion about arbitrary application data in Interests. 4. Data Packets Stapp Expires July 12, 2015 [Page 10] Internet-Draft NDN Message Format Proposal January 2015 The NDN Data packet is specified as: DATA-PACKET := PACKET-HEADER DATA-TLV NAME-TLV [ NDN-TLV ... ] PACKET-HEADER := Common packet header area defined above, with packet-type == Data DATA-TLV := NDN-TLV with Type == DataMessage NAME-TLV := NDN-TLV with Type == Name 4.1. Message Header TODO -- describe any header options etc. 4.2. TLV Section The Name TLV must be present, and must be the first child of the Data message TLV. The Data message contains an opaque blob of data in the ContentData TLV accompanied by a cryptographic signature. We propose continuing to use the CCNx approach here, with a few adjustments: o We allocate new TLV type codes for name information used in the KeyLocator's KeyName, rather than reusing the message-level Name TLVs. o The Timestamp is specified to use units of milliseconds. o For multi-segment content objects, the FinalSegmentID must be present in every Content message. 4.3. Data Signatures TODO -- Each Data message contains a digital signature. This section describes the process used to produce an NDN signature, encode it in a Data packet payload, and verify it at another node. 5. Nack Packets Stapp Expires July 12, 2015 [Page 11] Internet-Draft NDN Message Format Proposal January 2015 The NDN Nack packet is specified as: NACK-PACKET := PACKET-HEADER INTEREST-TLV NAME-TLV [ NDN-TLV ... ] PACKET-HEADER := Common packet header area defined above, with packet-type == Nack INTEREST-TLV := NDN-TLV with Type == InterestMessage NAME-TLV := NDN-TLV with Type == Name We believe that error-signalling offers value for NDN routers and for NDN end clients. We only specify a mechanism for errors resulting from routers' processing of Interest messages. NDN routers must maintain state about Interests they have forwarded, and they may be able to take advantage of that state to aid in congestion management and traffic engineering. When a node determines not to forward an Interest, it MAY generate an error message. It is possible to transform the original Interest packet into an error packet in a very direct way: the receiving node changes the packet-type to Nack, sets the packet header error code field to indicate the specific error encountered, and transmits the packet out the face on which the Interest arrived. This error message offers a basic level of value to other routers and, potentially, to the original client application or protocol stack. Routers on the return path are able to clear their PIT state, without waiting for a timeout. Routers may be able to attempt to re- route the original Interest if they have alternative forwarding paths available. A router can re-produce the original Interest simply clearing the error information from the header and re-transmitting it. A router that does not re-route an Interest after receiving an error may propagate the error by forwarding the Nack packet out the face associated with its entry for the Interest in its own PIT. TODO: should that 'may' be a 'should'? As the NDN routers propagate a Nack packet, it can make its way along the path from the node encountering an error back to the original client. The basic error message helps the client manage its own sense of the state of the network, identifying congestion issues or NDN names experiencing reachability problems. The error response to an Interest can also include a hint about the name prefix where the error condition was detected. We expect that the NDN router detecting an error may have a more-specific FIB entry Stapp Expires July 12, 2015 [Page 12] Internet-Draft NDN Message Format Proposal January 2015 than routers farther away. An NDN router should include a header option containing the number of name components in its FIB entry that most-closely matched the Interest's name. This hint may allow a router along the path the error will traverse back to the client to attempt to re-route the Interest if it has an alternative path. The name-prefix hint may also be useful to the original client stack (if the error propagates that far). NDN routers have to be careful not to allow malicious clients to inject fabricated error messages. An NDN Router must only accept or propagate error messages that arrive via faces associated with neighboring routers, and must not process or propagate an error message that does not match an entry in its PIT. DISCUSSION: There are some concerns about introducing a new Error or Nack message-type; some might feel that that threatens the NDN architectural principle permitting only Interest and Data messages. But ... it seems clearer than overloading either of the existing message types, so I'd like to offer it for discussion. 5.1. Packet Header The Nack packet header includes a field that carries a specific error code. Some 5.2. TLV Section The Nack message echoes back the Interest TLV message that provoked an error. 6. NDN TLVs TODO -- add a nice tidy table with info about which T codes can or can't appear in Interest vs Content messages. 'Freshness' vs. 'ContentExpiration': one is an interval, one an explicit wall-clock time. TODO better spec of signing procedure -- 'SignedFlags' -- allow the sender to include flags that can be signed? 6.1. NDN Name The NDN Name is represented as a series of NameComponent TLVs inside a Name TLV. The contents of each NameComponent are opaque octets. Stapp Expires July 12, 2015 [Page 13] Internet-Draft NDN Message Format Proposal January 2015 Large data items are transmitted using multiple Interest,Content exchanges for a single name. The NameSegment TLV carries an integer that is appended to the name to identify a specific sub-section of the data. The NameSegment data is a four-byte integer in network byte order. If a NameSegment sub-TLV is present, it must be the last sub-TLV in the Name TLV. More than one NameSegment sub-TLV must not be present in a Name TLV. TODO -- are four bytes enough: might there be very large files that are presented as very many 1KB or 4KB or 8KB messages? we could a) add a bigger TLV later, b) add a second 'generation' field that expands the range of the segment tlv, or c) specify the segment tlv to be eight bytes from the start. 6.2. ContentData The data in a Content message is represented as an opaque blob in a ContentData TLV. The data is application-specific. 6.3. Certificate Seems like something that should be supported - ccnx (0.6x) just bails. We'll need this... 6.4. PublisherPublicKeyDigest The PublisherPublicKeyDigest identifies the content publisher that signed the content data. The value is a SHA-256 digest of the public key of the publisher. This TLV must be present in each Content message. Its use in signatures and verification is described in Section 4.3. 6.5. PublisherPublicKeyName The PublisherPublicKeyName identifies the content publisher that signed the content data. The value is an NDN Name that can be used to retrieve the publisher key used to sign a Content object. Its use in signatures and verification is described in Section 4.3. 6.6. ContentDigest The ContentDigest TLV is optional in Content messages. If present, it contains the SHA-256 hash of the contents of the ContentData TLV, including the TLV Type and Length. Stapp Expires July 12, 2015 [Page 14] Internet-Draft NDN Message Format Proposal January 2015 6.7. PublicKey The PublicKey TLV is optional in Content messages. If present, it contains a public key corresponding to the private key used to sign the ContentData. Its use in signatures and verification is described in Section 4.3. 6.8. KeyName The KeyName TLV is optional in Content messages. If present, it contains an NDN name that can be used to retrieve keying information that can in turn be used to verify the signature of the ContentData. If present, the KeyName TLV only contains KeyNameComponent sub-TLVs. At least one KeyNameComponent TLV must be present in a KeyName TLV. Its use in signatures and verification is described in Section 4.3. 6.9. Signature The Signature TLV is a container for other TLVs that carry actual content signature data. The use of a container TLV also allows NDN nodes to skip past a group of related signature data TLVs efficiently if the node is not validating a particular signature. The container may also allow multiple signatures to be present, which may be useful in key agility or crypto algorithm agility. See Section 4.3 for details about content signatures. 6.10. SignatureBits The SignatureBits TLV contains the actual digital signature in a Content message. See Section 4.3 for details about content signatures. 6.11. Timestamp TODO -- what's the signed timestamp really for - what does it add? it gets stuck into the 'ccn_btree_content_payload' struct, but not used? and no one in ccnx seems to use the DTAG_Timestamp in their templates, so... 6.12. Witness TODO -- should we allocate the code-point for Merkle info, explicitly? then any future "extra" info would also get explicit types... Stapp Expires July 12, 2015 [Page 15] Internet-Draft NDN Message Format Proposal January 2015 6.13. DigestAlgorithm TODO -- default to sha-256. should we allocate more values? 6.14. ContentExpiration TODO -- prefer to have an absolute expiration time available, seems like it would be useful in some cases? 6.15. CacheTTL TODO -- ccnx's "freshness" acts like a cache TTL, seems worth keeping, maybe we should just ... give it a clearer name? and prefer less eccentric units: is seconds good enough? do we need millisecond resolution (really?) 6.16. TLV Type Codes enum ndn_tlv_e { NDN_TLV_Name = 1, NDN_TLV_NameComponent = 1, NDN_TLV_NameSegment = 2, NDN_TLV_ContentData = 4, NDN_TLV_Certificate = 5, NDN_TLV_SignedInfo = 6, NDN_TLV_ContentDigest = 7, NDN_TLV_PublicKey = 8, NDN_TLV_KeyName = 9, NDN_TLV_KeyNameComponent = 1, NDN_TLV_Signature = 10, NDN_TLV_Timestamp = 11, NDN_TLV_Witness = 12, NDN_TLV_SignatureBits = 13, NDN_TLV_DigestAlgorithm = 14, NDN_TLV_FinalSegmentID = 15, NDN_TLV_PublisherPublicKeyDigest = 16, NDN_TLV_PublisherPublicKeyName = 17, NDN_TLV_ContentExpiration = 18, NDN_TLV_CacheTTL = 19, NDN_TLV_VendorSpecific = 20, NDN_TLV_VendorId = 21 }; 7. Assigned Numbers Stapp Expires July 12, 2015 [Page 16] Internet-Draft NDN Message Format Proposal January 2015 7.1. Message Header Number Assignments The protocol Version is 1. The Packet Types are Interest (1), Content (2), and Nack (3). 7.2. Flag Bit Assignments One flag is defined for the Flags field in the Content message: NoCache (0x01). This flag is a hint to routers and caches that the message is not suitable for cacheing (a real-time interactive exchange for example.) 7.3. Error Code Assignments Several Error-code values are defined for the Nack message: NOROUTE (1), CONGESTED (2), NORESOURCE (3), POLICY (4). The NOROUTE error indicates that an NDN node was unable to forward the original Interest because it did not have a route to a publisher matching the message's Name. The CONGEST error indicates that a node did not forward the Interest because it detected congestion on the link associated with the FIB entry that matched the Name. The NORESOURCE error indicates that the node was unable to forward the Interest because of a shortage of internal resources. The POLICY error indicates that local administrative policy prevented further processing of the Interest. 7.4. TLV Number Ranges The standardized Type-code number space is partitioned into three regions: 1. Type code zero is reserved and must not be used. 2. Standardized values from 1 to 0x7fff 3. Experimental values from 0x8000 to 0xffff The vendor-specific TLV mechanism in Section 2.4 allows implementations additional flexibility. 8. The CCNx Scheme The CCNx project at PARC [TODO citation] has made a significant investment in an on-the-wire scheme, from which the community has learned a great deal. Subsequent experimentation has identified a number of drawbacks to the CCNx scheme that have led us to reconsider some of their choices. We aren't making an exhaustive analysis of Stapp Expires July 12, 2015 [Page 17] Internet-Draft NDN Message Format Proposal January 2015 the CCNx scheme here, but it seems useful to list some of the key points. o Inconsistent location of the NDN Name o Ambiguous use of Name-components (within the Name) for multiple purposes o Inefficient "versioning" and "meta-data" protocol extensions o Inefficient double-layer encoding o Confusion between data needed to operate the NDN protocol and application-specific functions o Multiple encodings for integers, timestamps, etc. o Reliance on specific byte-values within TLV values for critical protocol control functions o Issues producing error messages in response to Interests 9. Acknowledgements TODO -- acknowledge some folks here... 10. IANA Considerations All drafts must have an IANA section. This memo includes no requests to IANA. 11. Security Considerations TODO -- point back to signature section? 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Stapp Expires July 12, 2015 [Page 18] Internet-Draft NDN Message Format Proposal January 2015 Mark Stapp Cisco Systems, Inc. 55 Cambridge Pkwy. Cambridge, MA 02142 USA Phone: +1 978 936 0000 Email: mjs@cisco.com Stapp Expires July 12, 2015 [Page 19]