Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8569

Content-Centric Networking (CCNx) Semantics

Pages: 40
Experimental
Part 2 of 2 – Pages 21 to 40
First   Prev   None

Top   ToC   RFC8569 - Page 21   prevText

3. Names

A CCNx name is a composition of name segments. Each name segment carries a label identifying the purpose of the name segment, and a value. For example, some name segments are general names and some serve specific purposes such as carrying version information or the sequencing of many chunks of a large object into smaller, signed Content Objects. There are three different types of names in CCNx: prefix, exact, and full names. A prefix name is simply a name that does not uniquely identify a single Content Object, but rather a namespace or prefix of an existing Content Object name. An exact name is one that uniquely identifies the name of a Content Object. A full name is one that is exact and is accompanied by an explicit or implicit ConObjHash. The ConObjHash is explicit in an Interest and implicit in a Content Object. Note that a forwarder does not need to know any semantics about a name. It only needs to be able to match a prefix to forward Interests and match an exact or full name to forward Content Objects. It is not sensitive to the name segment types. The name segment labels specified in this document are given in Table 1. Name Segment is a general name segment, typically occurring in the routable prefix and user-specified content name. Interest Payload ID is a name segment to identify the Interest's payload. Application Components are a set of name segment types reserved for application use.
Top   ToC   RFC8569 - Page 22
   +-------------+-----------------------------------------------------+
   |     Type    | Description                                         |
   +-------------+-----------------------------------------------------+
   |     Name    | A generic name segment that includes arbitrary      |
   |   Segment   | octets.                                             |
   |             |                                                     |
   |   Interest  | An octet string that identifies the payload carried |
   |  Payload ID | in an Interest.  As an example, the Payload ID      |
   |             | might be a hash of the Interest Payload.  This      |
   |             | provides a way to differentiate between Interests   |
   |             | based on the payload solely through a name segment  |
   |             | without having to include all the extra bytes of    |
   |             | the payload itself.                                 |
   |             |                                                     |
   | Application | An application-specific payload in a name segment.  |
   |  Components | An application may apply its own semantics to these |
   |             | components.  A good practice is to identify the     |
   |             | application in a name segment prior to the          |
   |             | application component segments.                     |
   +-------------+-----------------------------------------------------+

                     Table 1: CCNx Name Segment Types

   At the lowest level, a forwarder does not need to understand the
   semantics of name segments; it need only identify name segment
   boundaries and be able to compare two name segments (both label and
   value) for equality.  The forwarder matches names segment by segment
   against its forwarding table to determine a next hop.
Top   ToC   RFC8569 - Page 23

3.1. Name Examples

This section uses the CCNx URI [ccnx-uri] representation of CCNx names. Note that as per the message grammar, an Interest must have a Name with at least one name segment that must have at least 1 octet of value. A Content Object must have a similar name or no name at all. The FIB, on the other hand, could have 0-length names (a default route), or a first name segment with no value, or a regular name. +--------------------------+----------------------------------------+ | Name | Description | +--------------------------+----------------------------------------+ | ccnx:/ | A 0-length name, corresponds to a | | | default route. | | | | | ccnx:/NAME= | A name with 1 segment of 0 length, | | | distinct from ccnx:/. | | | | | ccnx:/NAME=foo/APP:0=bar | A 2-segment name, where the first | | | segment is of type NAME and the second | | | segment is of type APP:0. | +--------------------------+----------------------------------------+ Table 2: CCNx Name Examples

3.2. Interest Payload ID

An Interest may also have a Payload field that carries state about the Interest but is not used to match a Content Object. If an Interest contains a payload, the Interest name should contain an Interest Payload ID (IPID). The IPID allows a PIT entry to correctly multiplex Content Objects in response to a specific Interest with a specific payload ID. The IPID could be derived from a hash of the payload or could be a Globally Unique Identifier (GUID) or a nonce. An optional Metadata field defines the IPID field so other systems can verify the IPID, such as when it is derived from a hash of the payload. No system is required to verify the IPID.

4. Cache Control

CCNx supports two fields that affect cache control. These determine how a cache or Content Store handles a Content Object. They are not used in the fast path; they are only used to determine if a Content Object can be injected onto the fast path in response to an Interest. The ExpiryTime is a field that exists within the signature envelope of a Validation Algorithm. It is the UTC time in milliseconds after
Top   ToC   RFC8569 - Page 24
   which the Content Object is considered expired and MUST no longer be
   used to respond to an Interest from a cache.  Stale content MAY be
   flushed from the cache.

   The Recommended Cache Time (RCT) is a field that exists outside the
   signature envelope.  It is the UTC time in milliseconds after which
   the publisher considers the Content Object to be of low value to
   cache.  A cache SHOULD discard it after the RCT, though it MAY keep
   it and still respond with it.  A cache MAY also discard the Content
   Object before the RCT time; there is no contractual obligation to
   remember anything.

   This formulation allows a producer to create a Content Object with a
   long ExpiryTime but short RCT and keep republishing the same signed
   Content Object over and over again by extending the RCT.  This allows
   a form of "phone home" where the publisher wants to periodically see
   that the content is being used.

5. Content Object Hash

CCNx allows an Interest to restrict a response to a specific hash. The hash covers the Content Object message body and the validation sections, if present. Thus, if a Content Object is signed, its hash includes that signature value. The hash does not include the fixed or hop-by-hop headers of a Content Object. Because it is part of the matching rules (see Section 9), the hash is used at every hop. There are two options for matching the Content Object Hash restriction in an Interest. First, a forwarder could compute for itself the hash value and compare it to the restriction. This is an expensive operation. The second option is for a border device to compute the hash once and place the value in a header (ConObjHash) that is carried through the network. The second option, of course, removes any security properties from matching the hash, so it SHOULD only be used within a trusted domain. The header SHOULD be removed when crossing a trust boundary.

6. Link

A Link is the tuple {Name, [KeyIdRestr], [ContentObjectHashRestr]}. The information in a Link comprises the fields of an Interest that would retrieve the Link target. A Content Object with PayloadType of "Link" is an object whose payload is one or more Links. This tuple may be used as a KeyLink to identify a specific object with the certificate-wrapped key. It is RECOMMENDED to include at least one of either KeyId restriction or Content Object Hash restriction. If neither restriction is present, then any Content Object with a matching name from any publisher could be returned.
Top   ToC   RFC8569 - Page 25

7. Hashes

Several protocol fields use cryptographic hash functions, which must be secure against attack and collisions. Because these hash functions change over time, with better ones appearing and old ones falling victim to attacks, it is important that a CCNx protocol implementation supports hash agility. In this document, we suggest certain hashes (e.g., SHA-256), but a specific implementation may use what it deems best. The normative CCNx Messages [RFC8609] specification should be taken as the definition of acceptable hash functions and uses.

8. Validation

8.1. Validation Algorithm

The Validator consists of a ValidationAlgorithm that specifies how to verify the message and a ValidationPayload containing the validation output, e.g., the digital signature or MAC. The ValidationAlgorithm section defines the type of algorithm to use and includes any necessary additional information. The validation is calculated from the beginning of the CCNx Message through the end of the ValidationAlgorithm section (i.e., up to but not including the validation payload). We refer to this as the validation region. The ValidationPayload is the integrity value bytes, such as a MAC or signature. The CCNx Message Grammar (Section 2.1) shows the allowed validation algorithms and their structure. In the case of a Vendor algorithm, the vendor may use any desired structure. A Validator can only be applied to an Interest or a Content Object, not an Interest Return. An Interest inside an Interest Return would still have the original validator, if any. The grammar allows multiple Vendor extensions to the validation algorithm. It is up to the vendor to describe the validation region for each extension. A vendor may, for example, use a regular signature in the validation algorithm, then append a proprietary MIC to allow for in-network error checking without using expensive signature verification. As part of this specification, we do not allow for multiple Validation Algorithm blocks apart from these vendor methods.
Top   ToC   RFC8569 - Page 26

8.2. Message Integrity Codes

If the validation algorithm is CRC32C, then the validation payload is the output of the CRC over the validation region. This validation algorithm allows for an optional signature time (SigTime) to timestamp when the message was validated (calling it a "signature" time is a slight misnomer, but we reuse the same field for this purpose between MICs, MACs, and signatures). MICs are usually used with an Interest to avoid accidental in-network corruption. They are usually not used on Content Objects because the objects are either signed or linked to by hash chains, so the CRC32C is redundant.

8.3. Message Authentication Codes

If the validation algorithm is HMAC-SHA256, then the validation payload is the output of the HMAC over the validation region. The validation algorithm requires a KeyId and allows for a signature time (SigTime) and KeyLink. The KeyId field identifies the shared secret used between two parties to authenticate messages. These secrets SHOULD be derived from a key exchange protocol such as [ccnx-ke]. The KeyId, for a shared secret, SHOULD be an opaque identifier not derived from the actual key; an integer counter, for example, is a good choice. The signature time is the timestamp when the authentication code was computed and added to the messages. The KeyLink field in a MAC indicates how to negotiate keys and should point towards the key exchange endpoint. The use of a key negotiation algorithm is beyond the scope of this specification, and a key negotiation algorithm is not required to use this field.

8.4. Signature

Signature-validation algorithms use public key cryptographic algorithms such as RSA and the Elliptic Curve Digital Signature Algorithm (ECDSA). This specification and the corresponding wire encoding [RFC8609] only support three specific signature algorithms: RSA-SHA256, EC-SECP-256K1, and EC-SECP-384R1. Other algorithms may be added in through other documents or by using experimental or vendor-validation algorithm types.
Top   ToC   RFC8569 - Page 27
   A signature that is public key based requires a KeyId field and may
   optionally carry a signature time, an embedded public key, an
   embedded certificate, and a KeyLink.  The signature time behaves as
   normal to timestamp when the signature was created.  We describe the
   use and relationship of the other fields here.

   It is not common to use embedded certificates, as they can be very
   large and may have validity periods different than the validated
   data.  The preferred method is to use a KeyLink to the validating
   certificate.

   The KeyId field in the ValidationAlgorithm identifies the public key
   used to verify the signature.  It is similar to a Subject Key
   Identifier from X.509 (Section 4.2.1.2 of [RFC5280]).  We define the
   KeyId to be a cryptographic hash of the public key in DER form.  All
   implementations MUST support the SHA-256 digest as the KeyId hash.

   The use of other algorithms for the KeyId is allowed, and it will not
   cause problems at a forwarder because the forwarder only matches the
   digest algorithm and digest output and does not compute the digest
   (see Section 9).  It may cause issues with a Content Store, which
   needs to verify the KeyId and PublicKey match (see Section 2.4.3);
   though in this case, it only causes a cache miss and the Interest
   would still be forwarded to the publisher.  As long as the publisher
   and consumers support the hash, data will validate.

   As per Section 9, a forwarder only matches the KeyId to a KeyId
   restriction.  It does not need to look at the other fields such as
   the public key, certificate, or KeyLink.

   If a message carries multiples of the KeyId, public key, certificate,
   or KeyLink, an endpoint (consumer, cache, or Content Store) MUST
   ensure that any fields it uses are consistent.  The KeyId MUST be the
   corresponding hash of the embedded public key or certificate public
   key.  The hash function to use is the KeyId's HashType.  If there is
   both an embedded public key and a certificate, the public keys MUST
   be the same.

   A message SHOULD NOT have both a PublicKey and a KeyLink to a public
   key, as that is redundant.  It MAY have a PublicKey and a KeyLink to
   a certificate.

   A KeyLink in a first Content Object may point to a second Content
   Object with a DER-encoded public key in the PublicKey field and an
   optional DER-encoded X.509 certificate in the payload.  The second
   Content Object's KeyId MUST equal the first object's KeyId.  The
   second object's PublicKey field MUST be the public key corresponding
   to the KeyId.  That key must validate both the first and second
Top   ToC   RFC8569 - Page 28
   object's signature.  A DER-encoded X.509 certificate may be included
   in the second object's payload and its embedded public key MUST match
   the PublicKey.  It must be issued by a trusted authority, preferably
   specifying the valid namespace of the key in the distinguished name.
   The second object MUST NOT have a KeyLink; we do not allow for
   recursive key lookup.

9. Interest to Content Object Matching

A Content Object satisfies an Interest if and only if (a) the Content Object name, if present, exactly matches the Interest name, (b) the ValidationAlgorithm KeyId of the Content Object exactly equals the Interest KeyId restriction, if present, and (c) the computed Content Object Hash exactly equals the Interest Content Object Hash restriction, if present. The KeyId and KeyIdRestr use the Hash format (see Section 2.1). The Hash format has an embedded HashType followed by the hash value. When comparing a KeyId and KeyIdRestr, one compares both the HashType and the value. The matching rules are given by this predicate, which, if it evaluates true, means the Content Object matches the Interest. Ni = Name in the Interest (may not be empty), Ki = KeyIdRestr in the Interest (may be empty), and Hi = ContentObjectHashRestr in the Interest (may be empty). Likewise, No, Ko, and Ho are those properties in the Content Object, where No and Ko may be empty; Ho always exists (it is an intrinsic property of the Content Object). For binary relations, we use "&" for AND and "|" for OR. We use "E" for the EXISTS (not empty) operator and "!" for the NOT EXISTS operator. As a special case, if the Content Object Hash restriction in the Interest specifies an unsupported hash algorithm, then no Content Object can match the Interest, so the system should drop the Interest and MAY send an Interest Return to the previous hop. In this case, the predicate below will never get executed because the Interest is never forwarded. If the system is using the optional behavior of having a different system calculate the hash for it, then the system may assume all hash functions are supported and leave it to the other system to accept or reject the Interest. (!No | (Ni=No)) & (!Ki | (Ki=Ko)) & (!Hi | (Hi=Ho)) & (E No | E Hi) As one can see, there are two types of attributes one can match. The first term depends on the existence of the attribute in the Content Object while the next two terms depend on the existence of the attribute in the Interest. The last term is the "Nameless Object"
Top   ToC   RFC8569 - Page 29
   restriction that states that if a Content Object does not have a
   Name, then it must match the Interest on at least the Hash
   restriction.

   If a Content Object does not carry the Content Object Hash as an
   expressed field, it must be calculated in network to match against.
   It is sufficient within an autonomous system to calculate a Content
   Object Hash at a border router and carry it via trusted means within
   the autonomous system.  If a Content Object ValidationAlgorithm does
   not have a KeyId, then the Content Object cannot match an Interest
   with a KeyId restriction.

10. Interest Return

This section describes the process whereby a network element may return an Interest message to a previous hop if there is an error processing the Interest. The returned Interest may be further processed at the previous hop or returned towards the Interest origin. When a node returns an Interest, it indicates that the previous hop should not expect a response from that node for the Interest, i.e., there is no PIT entry left at the returning node. The returned message maintains compatibility with the existing TLV packet format (a fixed header, optional hop-by-hop headers, and the CCNx Message body). The returned Interest packet is modified in only two ways: o The PacketType is set to Interest Return to indicate a Feedback message. o The ReturnCode is set to the appropriate value to signal the reason for the return. The specific encodings of the Interest Return are specified in [RFC8609]. A forwarder is not required to send any Interest Return messages. A forwarder is not required to process any received Interest Return message. If a forwarder does not process Interest Return messages, it SHOULD silently drop them. The Interest Return message does not apply to a Content Object or any other message type.
Top   ToC   RFC8569 - Page 30
   An Interest Return message is a 1-hop message between peers.  It is
   not propagated multiple hops via the FIB.  An intermediate node that
   receives an Interest Return may take corrective actions or may
   propagate its own Interest Return to previous hops as indicated in
   the reverse path of a PIT entry.

10.1. Message Format

The Interest Return message looks exactly like the original Interest message with the exception of the two modifications mentioned above. The PacketType is set to indicate the message is an Interest Return, and the reserved byte in the Interest header is used as a Return Code. The numeric values for the PacketType and ReturnCodes are in [RFC8609].
Top   ToC   RFC8569 - Page 31

10.2. ReturnCode Types

This section defines the Interest Return ReturnCode introduced in this RFC. The numeric values used in the packet are defined in [RFC8609]. +----------------------+--------------------------------------------+ | Name | Description | +----------------------+--------------------------------------------+ | No Route (Section | The returning forwarder has no route to | | 10.3.1) | the Interest name. | | | | | HopLimit Exceeded | The HopLimit has decremented to 0 and | | (Section 10.3.2) | needs to forward the packet. | | | | | Interest MTU too | The Interest's MTU does not conform to the | | large (Section | required minimum and would require | | 10.3.3) | fragmentation. | | | | | No Resources | The node does not have the resources to | | (Section 10.3.4) | process the Interest. | | | | | Path error (Section | There was a transmission error when | | 10.3.5) | forwarding the Interest along a route (a | | | transient error). | | | | | Prohibited (Section | An administrative setting prohibits | | 10.3.6) | processing this Interest. | | | | | Congestion (Section | The Interest was dropped due to congestion | | 10.3.7) | (a transient error). | | | | | Unsupported Content | The Interest was dropped because it | | Object Hash | requested a Content Object Hash | | Algorithm (Section | restriction using a hash algorithm that | | 10.3.8) | cannot be computed. | | | | | Malformed Interest | The Interest was dropped because it did | | (Section 10.3.9) | not correctly parse. | +----------------------+--------------------------------------------+ Table 3: Interest Return Reason Codes
Top   ToC   RFC8569 - Page 32

10.3. Interest Return Protocol

This section describes the forwarder behavior for the various Reason codes for Interest Return. A forwarder is not required to generate any of the codes, but if it does, it MUST conform to this specification. If a forwarder receives an Interest Return, it SHOULD take these standard corrective actions. A forwarder is allowed to ignore Interest Return messages, in which case its PIT entry would go through normal timeout processes. o Verify that the Interest Return came from a next hop to which it actually sent the Interest. o If a PIT entry for the corresponding Interest does not exist, the forwarder should ignore the Interest Return. o If a PIT entry for the corresponding Interest does exist, the forwarder MAY do one of the following: * Try a different forwarding path, if one exists, and discard the Interest Return, or * Clear the PIT state and send an Interest Return along the reverse path. If a forwarder tries alternate routes, it MUST ensure that it does not use the same path multiple times. For example, it could keep track of which next hops it has tried and not reuse them. If a forwarder tries an alternate route, it may receive a second Interest Return, possibly of a different type than the first Interest Return. For example, node A sends an Interest to node B, which sends a No Route return. Node A then tries node C, which sends a Prohibited Interest Return. Node A should choose what it thinks is the appropriate code to send back to its previous hop. If a forwarder tries an alternate route, it should decrement the Interest Lifetime to account for the time spent thus far processing the Interest.

10.3.1. No Route

If a forwarder receives an Interest for which it has no route, or for which the only route is back towards the system that sent the Interest, the forwarder SHOULD generate a "No Route" Interest Return message.
Top   ToC   RFC8569 - Page 33
   How a forwarder manages the FIB table when it receives a No Route
   message is implementation dependent.  In general, receiving a No
   Route Interest Return should not cause a forwarder to remove a route.
   The dynamic routing protocol that installed the route should correct
   the route, or the administrator who created a static route should
   correct the configuration.  A forwarder could suppress using that
   next hop for some period of time.

10.3.2. HopLimit Exceeded

A forwarder MAY choose to send HopLimit Exceeded messages when it receives an Interest that must be forwarded off system and the HopLimit is 0.

10.3.3. Interest MTU Too Large

If a forwarder receives an Interest whose MTU exceeds the prescribed minimum, it MAY send an "Interest MTU Too Large" message, or it may silently discard the Interest. If a forwarder receives an "Interest MTU Too Large" response, it SHOULD NOT try alternate paths. It SHOULD propagate the Interest Return to its previous hops.

10.3.4. No Resources

If a forwarder receives an Interest and it cannot process the Interest due to lack of resources, it MAY send an Interest Return. A lack of resources could mean the PIT is too large or that there is some other capacity limit.

10.3.5. Path Error

If a forwarder detects an error forwarding an Interest, such as over a reliable link, it MAY send a Path-Error Interest Return indicating that it was not able to send or repair a forwarding error.

10.3.6. Prohibited

A forwarder may have administrative policies, such as access control lists (ACLs), that prohibit receiving or forwarding an Interest. If a forwarder discards an Interest due to a policy, it MAY send a Prohibited Interest Return to the previous hop. For example, if there is an ACL that says "/example/private" can only come from interface e0, but the forwarder receives one from e1, the forwarder must have a way to return the Interest with an explanation.
Top   ToC   RFC8569 - Page 34

10.3.7. Congestion

If a forwarder discards an Interest due to congestion, it MAY send a Congestion Interest Return to the previous hop.

10.3.8. Unsupported Content Object Hash Algorithm

If a Content Object Hash restriction specifies a hash algorithm the forwarder cannot verify, the Interest should not be accepted and the forwarder MAY send an Interest Return to the previous hop.

10.3.9. Malformed Interest

If a forwarder detects a structural or syntactical error in an Interest, it SHOULD drop the Interest and MAY send an Interest Return to the previous hop. This does not imply that any router must validate the entire structure of an Interest.

11. IANA Considerations

This document has no IANA actions.

12. Security Considerations

The CCNx protocol is an L3 network protocol, which may also operate as an overlay using other transports such as UDP or other tunnels. It includes intrinsic support for message authentication via a signature (e.g., RSA or elliptic curve) or message authentication code (e.g., HMAC). In lieu of an authenticator, it may instead use a message integrity check (e.g., SHA or CRC). CCNx does not specify an encryption envelope; that function is left to a high-layer protocol (e.g., [esic]). The CCNx message format includes the ability to attach MICs (e.g., CRC32C), MACs (e.g., HMAC), and signatures (e.g., RSA or ECDSA) to all packet types. This does not mean that it is a good idea to use an arbitrary ValidationAlgorithm, nor to include computationally expensive algorithms in Interest packets, as that could lead to computational DoS attacks. Applications should use an explicit protocol to guide their use of packet signatures. As a general guideline, an application might use a MIC on an Interest to detect unintentionally corrupted packets. If one wishes to secure an Interest, one should consider using an encrypted wrapper and a protocol that prevents replay attacks, especially if the Interest is being used as an actuator. Simply using an authentication code or signature does not make an Interest secure. There are several examples in the literature on how to secure ICN-style messaging [mobile] [ace].
Top   ToC   RFC8569 - Page 35
   As an L3 protocol, this document does not describe how one arrives at
   keys or how one trusts keys.  The CCNx Content Object may include a
   public key or certificate embedded in the object or may use the
   KeyLink field to point to a public key or certificate that
   authenticates the message.  One key-exchange specification is CCNxKE
   [ccnx-ke] [mobile], which is similar to the TLS 1.3 key exchange
   except it is over the CCNx L3 messages.  Trust is beyond the scope of
   an L3 protocol and left to applications or application frameworks.

   The combination of an ephemeral key exchange (e.g., CCNxKE [ccnx-ke])
   and an encapsulating encryption (e.g., [esic]) provides the
   equivalent of a TLS tunnel.  Intermediate nodes may forward the
   Interests and Content Objects but have no visibility inside.  It also
   completely hides the internal names in those used by the encryption
   layer.  This type of tunneling encryption is useful for content that
   has little or no cacheability, as it can only be used by someone with
   the ephemeral key.  Short-term caching may help with lossy links or
   mobility, but long-term caching is usually not of interest.

   Broadcast encryption or proxy re-encryption may be useful for content
   with multiple uses over time or many consumers.  There is currently
   no recommendation for this form of encryption.

   The specific encoding of messages will have security implications.
   [RFC8609] uses a type-length-value (TLV) encoding.  We chose to
   compromise between extensibility and unambiguous encodings of types
   and lengths.  Some TLV encodings use variable-length "T" and
   variable-length "L" fields to accommodate a wide gamut of values
   while trying to be byte efficient.  Our TLV encoding uses a fixed-
   length 2-byte "T" and 2-byte "L".  Using a fixed-length "T" and "L"
   field solves two problems.  The first is aliases.  If one is able to
   encode the same value, such as %x02 and %x0002, in different byte
   lengths, then one must decide if they mean the same thing, if they
   are different, or if one is illegal.  If they are different, then one
   must always compare on the buffers, not the integer equivalents.  If
   one is illegal, then one must validate the TLV encoding, every field
   of every packet at every hop.  If they are the same, then one has the
   second problem: how to specify packet filters.  For example, if a
   name has 6 name components, then there are 7 T's and 7 L's, each of
   which might have up to 4 representations of the same value.  That
   would be 14 fields with 4 encodings each, or 1001 combinations.  It
   also means that one cannot compare, for example, a name via a memory
   function as one needs to consider that any embedded "T" or "L" might
   have a different format.

   The Interest Return message has no authenticator from the previous
   hop.  Therefore, the payload of the Interest Return should only be
   used locally to match an Interest.  A node should never forward that
Top   ToC   RFC8569 - Page 36
   Interest Payload as an Interest.  It should also verify that it sent
   the Interest in the Interest Return to that node and not allow anyone
   to negate Interest messages.

   Caching nodes must take caution when processing Content Objects.  It
   is essential that the Content Store obey the rules outlined in
   Section 2.4.3 to avoid certain types of attacks.  CCNx 1.0 has no
   mechanism to work around an undesired result from the network (there
   are no "excludes"), so if a cache becomes poisoned with bad content,
   it might cause problems retrieving content.  There are three types of
   access to content from a Content Store: unrestricted, signature
   restricted, and hash restricted.  If an Interest has no restrictions,
   then the requester is not particular about what they get back, so any
   matching cached object is OK.  In the hash-restricted case, the
   requester is very specific about what they want and the Content Store
   (and every forward hop) can easily verify that the content matches
   the request.  In the signature-restricted case (often used for
   initial manifest discovery), the requester only knows the KeyId that
   signed the content.  It is this case that requires the closest
   attention in the Content Store to avoid amplifying bad data.  The
   Content Store must only respond with a Content Object if it can
   verify the signature; this means either the Content Object carries
   the public key inside it or the Interest carries the public key in
   addition to the KeyId.  If that is not the case, then the Content
   Store should treat the Interest as a cache miss and let an endpoint
   respond.

   A user-level cache could perform full signature verification by
   fetching a public key or certificate according to the KeyLink.  That
   is not, however, a burden we wish to impose on the forwarder.  A
   user-level cache could also rely on out-of-band attestation, such as
   the cache operator only inserting content that it knows has the
   correct signature.

   The CCNx grammar allows for hash-algorithm agility via the HashType.
   It specifies a short list of acceptable hash algorithms that should
   be implemented at each forwarder.  Some hash values only apply to end
   systems, so updating the hash algorithm does not affect forwarders;
   they would simply match the buffer that includes the type-length-hash
   buffer.  Some fields, such as the ConObjHash, must be verified at
   each hop, so a forwarder (or related system) must know the hash
   algorithm; it could cause backward compatibility problems if the hash
   type is updated.  [RFC8609] is the authoritative source for per-
   field-allowed hash types in that encoding.

   A CCNx name uses binary matching whereas a URI uses a case-
   insensitive hostname.  Some systems may also use case-insensitive
   matching of the URI path to a resource.  An implication of this is
Top   ToC   RFC8569 - Page 37
   that human-entered CCNx names will likely have case or non-ASCII
   symbol mismatches unless one uses a consistent URI normalization to
   the CCNx name.  It also means that an entity that registers a CCNx
   routable prefix, say "ccnx:/example.com", would need separate
   registrations for simple variations like "ccnx:/Example.com".  Unless
   this is addressed in URI normalization and routing protocol
   conventions, there could be phishing attacks.

   For a more general introduction to ICN-related security concerns and
   approaches, see [RFC7927] and [RFC7945].

13. References

13.1. Normative References

[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>. [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>.

13.2. Informative References

[ace] Shang, W., Yu, Y., Liang, T., Zhang, B., and L. Zhang, "NDN-ACE: Access Control for Constrained Environments over Named Data Networking", NDN Technical Report NDN-0036, December 2015, <http://new.named-data.net/ wp-content/uploads/2015/12/ndn-0036-1-ndn-ace.pdf>. [befrags] Mosko, M. and C. Tschudin, "ICN "Begin-End" Hop by Hop Fragmentation", Work in Progress, draft-mosko-icnrg- beginendfragment-02, December 2016. [ccn-lite] Tschudin, C., et al., "CCN-lite", University of Basel, 2011-2019, <http://ccn-lite.net>. [ccnx-ke] Mosko, M., Uzun, E., and C. Wood, "CCNx Key Exchange Protocol Version 1.0", Work in Progress, draft-wood-icnrg- ccnxkeyexchange-02, March 2017. [ccnx-registry] IANA, "Content-Centric Networking (CCNx)", <https://www.iana.org/assignments/ccnx>.
Top   ToC   RFC8569 - Page 38
   [ccnx-uri] Mosko, M. and C. Wood, "The CCNx URI Scheme", Work in
              Progress, draft-mosko-icnrg-ccnxurischeme-01, April 2016.

   [chunking] Mosko, M., "CCNx Content Object Chunking", Work in
              Progress, draft-mosko-icnrg-ccnxchunking-02, June 2016.

   [cicn]     FD.io, "Community ICN (CICN)", February 2017,
              <https://wiki.fd.io/index.php?title=Cicn&oldid=7191>.

   [dart]     Garcia-Luna-Aceves, J. and M. Mirzazad-Barijough, "A
              Light-Weight Forwarding Plane for Content-Centric
              Networks", International Conference on Computing,
              Networking, and Communications (ICNC),
              DOI 10.1109/ICCNC.2016.7440637, February 2016,
              <https://arxiv.org/pdf/1603.06044.pdf>.

   [eprise-numbers]
              IANA, "IANA Private Enterprise Numbers",
              <https://www.iana.org/assignments/enterprise-numbers>.

   [esic]     Mosko, M. and C. Wood, "Encrypted Sessions In CCNx
              (ESIC)", Work in Progress, draft-wood-icnrg-esic-01,
              September 2017.

   [flic]     Tschudin, C. and C. Wood, "File-Like ICN Collection
              (FLIC)", Work in Progress, draft-tschudin-icnrg-flic-03,
              March 2017.

   [mobile]   Mosko, M., Uzun, E., and C. Wood, "Mobile Sessions in
              Content-Centric Networks", IFIP Networking Conference
              (IFIP Networking) and Workshops,
              DOI 10.23919/IFIPNetworking.2017.8264861, June 2017,
              <https://dl.ifip.org/db/conf/networking/
              networking2017/1570334964.pdf>.

   [ndn]      UCLA, "Named Data Networking", 2019,
              <https://www.named-data.net>.

   [nnc]      Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
              Briggs, N., and R. Braynard, "Networking Named Content",
              Proceedings of the 5th International Conference on
              Emerging Networking Experiments and Technologies,
              DOI 10.1145/1658939.1658941, December 2009,
              <https://dx.doi.org/10.1145/1658939.1658941>.
Top   ToC   RFC8569 - Page 39
   [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>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC7927]  Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
              Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
              "Information-Centric Networking (ICN) Research
              Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
              <https://www.rfc-editor.org/info/rfc7927>.

   [RFC7945]  Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S.,
              and G. Boggia, "Information-Centric Networking: Evaluation
              and Security Considerations", RFC 7945,
              DOI 10.17487/RFC7945, September 2016,
              <https://www.rfc-editor.org/info/rfc7945>.

   [RFC8609]  Mosko, M., Solis, I., and C. Wood, "Content-Centric
              Networking (CCNx) Messages in TLV Format", RFC 8609,
              DOI 10.17487/RFC8609, July 2019,
              <https://www.rfc-editor.org/info/rfc8609>.

   [selectors]
              Mosko, M., "CCNx Selector Based Discovery", Work in
              Progress, draft-mosko-icnrg-selectors-01, May 2019.

   [terminology]
              Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran,
              D., and C. Tschudin, "Information-Centric Networking
              (ICN): CCN and NDN Terminology", Work in Progress,
              draft-irtf-icnrg-terminology-04, June 2019.

   [trust]    Tschudin, C., Uzun, E., and C. Wood, "Trust in
              Information-Centric Networking: From Theory to Practice",
              25th International Conference on Computer Communication
              and Networks (ICCCN), DOI 10.1109/ICCCN.2016.7568589,
              August 2016, <https://doi.org/10.1109/ICCCN.2016.7568589>.
Top   ToC   RFC8569 - Page 40

Authors' Addresses

Marc Mosko PARC, Inc. Palo Alto, California 94304 United States of America Phone: +01 650-812-4405 Email: marc.mosko@parc.com Ignacio Solis LinkedIn Mountain View, California 94043 United States of America Email: nsolis@linkedin.com Christopher A. Wood University of California Irvine Irvine, California 92697 United States of America Phone: +01 315-806-5939 Email: woodc1@uci.edu