WO2020093655A1

WO2020093655A1 - Method and apparatus for inter-domain trust interest and content forwarding

Info

Publication number: WO2020093655A1
Application number: PCT/CN2019/082258
Authority: WO
Inventors: Ravishankar Ravindran; Aytac Azgin
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2018-11-08
Filing date: 2019-04-11
Publication date: 2020-05-14

Abstract

A method implemented by content network element (NE) in a domain of a multi-domain network comprises receiving, by a receiver of the content NE, a packet comprising a content name associated with a content object and trust enforcement data, the trust enforcement data comprising a list of identifiers identifying a plurality of trusted domains within the multi-domain network, and determining, by a processor coupled to the receiver, whether to process the packet based on whether the domain is identified in the list of identifiers identifying the plurality of trusted domains.

Description

Method and Apparatus for Inter-Domain Trust Interest and Content Forwarding

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims the benefit of benefit of U.S. Provisional Patent Application No. 62/757,382 filed November 8, 2018 by Ravishankar Ravindran, et. al., and entitled “Method and Apparatus for Inter-Domain Trust Interest and Content Forwarding, ” which is incorporated herein by reference as if reproduced in its entirety.

FIELD OF INVENTION

The present disclosure pertains to the field of information-centric networking. In particular, the present disclosure relates to securing packets and data packets that are transmitted in a multi-domain network implementing information-centric networking.

BACKGROUND

In a traditional network implementing a Transmission Control Protocol/Internet Protocol (TCP/IP) model, a consumer requesting content needs to first map a Uniform Resource Locator (URL) of the content to a producer having a content server. The producer mostly stays the same for a length of the session. The session may be bound to the server, and the goal of the session is to transfer the requested content from the producer to the consumer. In this host-centric networking paradigm, the core networking primitives revolve around naming hosts and network interfaces. Network devices are only configured to forward packets to the destination address.

In a network implementing information-centric networking, a domain-wide unique name is assigned to each information object that is part of a content delivery framework, including routers, switches, or servers. Information objects may include data content, such as video clips or web pages. In a network implementing information-centric networking, content routers are responsible for routing user requests to a producer and content to a requesting consumer. The content routers route packets based on name prefixes, which may be full content names or name prefixes of content names, instead of network addresses. Content delivery, such as publishing, requesting, and managing of the content, is based on the name of the content instead of the location of the content.

Networks implementing information-centric networking differ from Internet Protocol (IP) networks as networks implementing information-centric networking perform in- network content caching on a temporary basis or a more persistent basis. This may allow content to be served from the network instead of an original content server, and thus may substantially improve user experience. The cached content may be used for real time data that is fetched by the user or for persistent data that belongs to the user or to a content provider, for example, a third party provider.

SUMMARY

According to a first aspect of the present disclosure, there is provided a content network element (NE) . The content NE comprises a receiver configured to receive an interest packet comprising a content name associated with a content object and trust enforcement data, the trust enforcement data comprising a list of identifiers identifying a plurality of trusted domains within the multi-domain network, and a processor coupled to the receiver and configured to determine whether to process the interest packet based on whether the domain is identified in the list of identifiers identifying the plurality of trusted domains.

In a first implementation of the content NE according to the first aspect, the trust enforcement data further comprises a public key for each of the plurality of trusted domains.

In a second implementation of the content NE according to the first aspect or any preceding implementation of the first aspect, the trust enforcement data further comprises a signature associated with a producer of the content object.

In a third implementation of the content NE according to the first aspect or any preceding implementation of the first aspect, the content NE further comprises a memory coupled to the processor and configured to store a pending interest table (PIT) , wherein the trust enforcement data comprises a signature of the producer, and wherein in response to determining that the domain is identified in the list of identifiers identifying the plurality of trusted domains, the processor is further configured to decrypt the interest packet using a private key associated with the domain, validate the signature of the producer included in the trust enforcement data, and create an entry in the PIT storing the content name in association with the trust enforcement data, wherein data associated with a plurality of interest messages including the content name and the trust enforcement data is aggregated together in the entry.

In a fourth implementation of the content NE according to the first aspect or any preceding implementation of the first aspect, the content NE further comprises a memory coupled to the processor and configured to store a content store, and wherein, in response to determining that the domain is identified in the list of identifiers identifying the plurality of trusted domains and determining that the content object is stored at the content store, a transmitter coupled to the processor is further configured to transmit the content object stored at the content store back to a consumer.

In a fifth implementation of the content NE according to the first aspect or any preceding implementation of the first aspect, the content NE further comprises a transmitter coupled to the processor, wherein the content name is encrypted within the interest packet, and wherein in response to determining that the domain is not identified in the list of identifiers identifying the plurality of trusted domains, the transmitter is configured to forward the interest packet to a next hop according to a forwarding label of the interest packet and a forwarding information database (FIB) of the content NE without inspecting the interest packet.

In a sixth implementation of the content NE according to the first aspect or any preceding implementation of the first aspect, the processor is further configured to generate an initial interest packet before receiving the interest packet, wherein an identifier of the domain is appended to the initial interest packet, wherein the content NE further comprises a transmitter coupled to the processor and configured to forward the initial interest packet to a next hop according to a forwarding label of the initial interest packet, wherein the receiver is further configured to receive a manifest comprising information regarding the content object and the trust enforcement data from a producer in response to transmitting the initial interest packet.

In a seventh implementation of the content NE according to the first aspect or any preceding implementation of the first aspect, the processor is further configured to classify the interest packet as including trust enforcement data before determining whether to process the interest packet based on whether the domain is identified in the list of identifiers identifying the plurality of trusted domains.

According to a second aspect of the present disclosure, there is provided a content NE implemented in a domain of a multi-domain network. The content NE comprises a receiver configured to receive a data packet comprising a content object and trust enforcement data, the trust enforcement data comprising a list of identifiers identifying a plurality of trusted domains within the multi-domain network; and a processor coupled to the receiver and configured to determine whether to process the data packet based on whether the domain is identified in the list of identifiers identifying the plurality of trusted domains.

In a first implementation of the content NE according to the second aspect, the receiver is further configured to receive an interest packet comprising a content name associated with the content object and the trust enforcement data, and wherein the data packet is received from a producer of the content object after receiving the interest packet.

In a second implementation of the content NE according to the first aspect or any preceding implementation of the second aspect, before receiving the data packet, the receiver is further configured to receive a manifest from a producer of the content object, the manifest comprising information regarding the content object and the trust enforcement data.

In a third implementation of the content NE according to the first aspect or any preceding implementation of the second aspect, the content NE further comprising a memory coupled to the processor and configured to store a pending interest table (PIT) , wherein the trust enforcement data further comprises a signature of a producer of the content object, wherein in response to determining that the domain is identified in the list of identifiers identifying the plurality of trusted domains, the processor is further configured to decrypt the data packet using a private key associated with at least one of the producer or the domain, validate a signature included in the trust enforcement data, and determine whether an entry for the content object exists in the PIT.

In a fourth implementation of the content NE according to the first aspect or any preceding implementation of the second aspect, the content NE further comprising a memory coupled to the processor and configured to store a forwarding information database (FIB) and a content store, and wherein, in response to the entry for the content object exists in the PIT, the processor is further configured to delete the entry from the PIT, remove a forwarding label from the data packet, and cache the content object in association with the trust enforcement data in the content store, wherein the content NE further comprises a transmitter configured to transmit the content object to a consumer based on the PIT.

According to a third aspect of the present disclosure, there is provided a method implemented by a content NE in a domain of a multi-domain network. The method comprises receiving, by a receiver of the content NE, a packet comprising a content name associated with a content object and trust enforcement data, the trust enforcement data comprising a list of identifiers identifying a plurality of trusted domains within the multi-domain network, and determining, by a processor coupled to the receiver, whether to process the packet based on whether the domain is identified in the list of identifiers identifying the plurality of trusted domains.

In a first implementation of the method according to the third aspect, the packet is an interest packet received from a consumer requesting the content object from a producer.

In a second implementation of the method according to the third aspect or any preceding implementation of the third aspect, the packet is a data packet received from a producer comprising the content object requested by a consumer.

In a third implementation of the method according to the third aspect or any preceding implementation of the third aspect, the trust enforcement data further comprises a private key for each of the plurality of trusted domains.

In a fourth implementation of the method according to the third aspect or any preceding implementation of the third aspect, the trust enforcement data further comprises a signature associated with a producer of the content object.

In a fifth implementation of the method according to the third aspect or any preceding implementation of the third aspect, the packet is an interest packet received from a consumer requesting the content object, and wherein in response to determining that the domain is identified in the list of identifiers identifying the plurality of trusted domains, the method further comprises decrypt, by the processor, the interest packet using a private key associated with at least one of the producer or the domain, create, by the processor, an entry in a pending interest table (PIT) storing the content name in association with the trust enforcement data, and forward, by a transmitter coupled to the processor, the content object in response to determining that the content object is cached at the content NE.

In a sixth implementation of the method according to the third aspect or any preceding implementation of the third aspect, the packet is a data packet comprising the content object received from a producer, and wherein the method further comprises forward, by a transmitter coupled to the processor, the content object to a consumer requesting the content object based on an entry for the content object in the pending interest table (PIT) , and cache, by a memory coupled to the processor, the content object locally at the content NE.

According to a fourth aspect of the present disclosure, there is provided a consumer implemented in a multi-domain network. The consumer comprises a transmitter configured to transmit an interest packet comprising a content name associated with a content object to a producer; and a receiver configured to receive a manifest comprising information regarding the content object and trust enforcement data from the producer, the trust enforcement data comprising a list of identifiers identifying a plurality of trusted domains within the multi-domain network.

In a first implementation of the consumer according to the fourth aspect, the consumer further comprises a processor configured to encrypt a second interest packet comprising the content name and the trust enforcement data in response to determining that a neighboring domain is not identified in the trust enforcement data, wherein the transmitter is further configured to transmit the second interest packet to a border content network element (NE) of the neighboring domain.

In a second implementation of the consumer according to the fourth aspect or any preceding implementation of the fourth aspect, the receiver is further configured to receive a data packet comprising the content object and the trust enforcement data.

According to a fifth aspect of the present disclosure, there is provided a producer implemented in a multi-domain network. The producer comprises a receiver configured to receive an interest packet comprising a content name associated with a content object from a consumer, and a transmitter configured to transmit a manifest comprising information regarding the content object and trust enforcement data to the consumer, the trust enforcement data comprising a list of identifiers identifying a plurality of trusted domains within the multi-domain network.

In a first implementation of the producer according to the fifth aspect, the producer further comprises a processor configured to encrypt the manifest before transmitting the manifest and in response to determining that a neighboring domain is not identified in the trust enforcement data.

In a second implementation of the producer according to the fifth aspect or any preceding implementation of the fifth aspect, the producer further comprises a processor configured to encrypt the content object before transmitting the content object to the consumer and in response to determining that a neighboring domain is not identified in the trust enforcement data.

In a third implementation of the producer according to the fifth aspect or any preceding implementation of the fifth aspect, the producer further comprises a processor configured to extract identifiers of a plurality of domains through which an initial interest packet traveled, determine a plurality of trusted domains from the plurality of domains through which the initial interest packet traveled, and generate a list of trusted domains comprising the plurality of trusted domains.

For the purpose of clarity, any one of the foregoing embodiments may be combined with any one or more of the other foregoing embodiments to create a new embodiment within the scope of the present disclosure.

These and other features will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of this disclosure, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.

FIG. 1 is a diagram illustrating an embodiment of a multi-domain network implementing ICN and configured to provide content as requested by a consumer according to various embodiments of the disclosure.

FIG. 2 is a diagram illustrating an embodiment of an NE in the multi-domain network according to various embodiments of the disclosure.

FIGS. 3A-D are message sequence diagrams illustrating an example of how to implement and enforce trust enforcement data when transmitting interest packets and data packets in the multi-domain network according to various embodiments of the disclosure.

FIG. 4 is a diagram illustrating a method of identifying the trusted domains within the multi-domain network for a consumer according to various embodiments of the disclosure.

FIG. 5 is a diagram illustrating a method of processing an interest packet at an NE of the multi-domain network according to various embodiments of the disclosure.

FIG. 6 is a diagram illustrating a method of processing a data packet at an NE of the multi-domain network according to various embodiments of the disclosure.

FIGS. 7A-B are flowcharts illustrating a method of processing an interest packet at an ingress border NE of a domain within the multi-domain network according to various embodiments of the disclosure.

FIG. 8 is a flowchart illustrating a method of processing an interest packet at a core NE of a domain within the multi-domain network according to various embodiments of the disclosure.

FIG. 9 is a flowchart illustrating a method of processing an interest packet at an egress border NE of a domain within the multi-domain network according to various embodiments of the disclosure.

FIG. 10 is a flowchart illustrating a method of processing a data packet at an ingress border NE of a domain within the multi-domain network according to various embodiments of the disclosure.

FIG. 11 is a flowchart illustrating a method of processing a data packet at a core NE of a domain within the multi-domain network according to various embodiments of the disclosure.

FIG. 12 is a flowchart illustrating a method of processing a data packet at an egress border NE of a domain within the multi-domain network according to various embodiments of the disclosure.

FIG. 13 is a flowchart illustrating a method for processing packets with trust enforcement data within the multi-domain network according to various embodiments of the disclosure.

FIG. 14 is a diagram illustrating an apparatus for processing interest packets and data packets according to various embodiments of the disclosure.

FIG. 15 is a diagram illustrating an apparatus for transmitting and receiving trust enforcement data according to various embodiments of the disclosure.

DETAILED DESCRIPTION

It should be understood at the outset that, although an illustrative implementation of one or more embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.

Typically, interest packets and data packets are transmitted through the multi-domain network implementing information-centric networking without securing the data that is being transmitted in the interest packets and data packets. However, consumers and producers within the multi-domain network may want to prevent devices within particular untrusted domains from being capable of inspecting and processing the data within the interest packets and data packets. For example, consumers may not want third party devices within an untrusted domain to have knowledge of the content being requested by the interest packets. Similarly, producers may not want third party devices within an untrusted domain to be able to access or locally cache content originating from the producer. The embodiments of this present disclosure are directed to methods and apparatuses that facilitate securing the interest packets and the data packets such that devices within an untrusted domain of the multi-domain network may not inspect or process the data within the interest packets and data packets.

FIG. 1 is a diagram illustrating an embodiment of a multi-domain network 100 configured to provide content from a producer 103 as requested by a consumer 106 according to various embodiments of the disclosure. The multi-domain network 100 may be, but is not limited to, a Named Data Network (NDN) , Information Centric Network (ICN) , Content Centric Network (CCN) , Content Oriented Network (CON) , Data Oriented Network (DON) , or Content Based Network (CBN) . A multi-domain network 100 includes a type of network architecture that focuses on information delivery related to content objects. Content objects may be, for example, content, data streams, services, user entities, and/or devices. In the multi-domain network 100, content objects are assigned with application-based content names, which are used to address the content objects and decouple the content objects from their respective locations. In one embodiment, the multi-domain network 100 may be similar to the ICNs described in the Internet Research Task Force (IRTF) Request for Comments (RFC) 7945, entitled “Information-Centric Networking: Evaluation and Security Considerations, ” by K. Pentikousis, dated September 6, 2016.

As shown in FIG. 1, the multi-domain network 100 comprises a consumer 103, a producer 106, and one or more domains 105A-D (also referred to herein as autonomous systems (ASs) ) , each of which are interconnected by a plurality of interfaces 131. The consumer 103 may be a user equipment (UE) , such as, for example, a mobile phone, mobile tablet, wearable device, Internet of Things (IoT) device, or personal computer. The consumer 103 may be configured to transmit interest packets 166 requesting one or more content objects from a producer 106. The producer 106 may be, for example, a data center, service provider, or a central office configured to provide requested content to a consumer 103.

Each of the domains 105A-D may be a sub-network of the multi-domain network 100 and operated by a different administrative entity. Each of the domains 105A-D comprises a plurality of NEs 110-122 interconnected by interfaces 132. The

interfaces

131 and 132 may include wired links or wireless links between the NEs 110-122, input ports at the NEs 110-122, and/or output ports at the NEs 110-122.

As shown in FIG. 1, domain 105A includes NEs 110-112 and 119, of which NEs 110-112 may be content NEs 110-112 and NE 119 may be a core NE 119. A content NE 110-112 may be a physical device, such as a router or a network switch, or a logical device, configured to perform switching, routing, and name based content forwarding functions in the multi-domain network 100. A content NE 110-112 may further comprise a memory configured to store a content store, local filters, a pending interest table (PIT) , a forwarding information base (FIB) , and/or other data stores configured to facilitate forwarding messages between the NEs 110-122, the consumer 103, and the producer 106.

A content store may be used to cache or store content objects for a period of time. The content store may also be used to receive and associate interests (user requests for content) received in interest packets 166 with corresponding content data (requested content) received in data packets 177. A PIT stores information on the forwarded interest packets 166, which are then subsequently used to transport data packets 177 with the content requested back to the consumer 103. The FIB stores information regarding content names with corresponding interfaces for next hops on which the interests and content data are forwarded and received. The FIB entries may indicate the next hops on which messages (interests and data) may be forwarded. The FIB may be a data structure which may be maintained and operated to process content interest and data at a data plane or forwarding plane.

The core NE 119 may be a physical device, such as a router or a network switch, or a logical device, configured to perform switching and routing functions in the multi-domain network 100. For example, the core NE 119 may include a content store, a PIT, and an FIB that is used to perform name based forwarding of interest packets 166 and data packets 177. In an embodiment, the core NE 119 may be an intermediate node in the domain 105A. While the domain 105A is shown to include three content NEs 110-112 and one core NE 119, it should be appreciated that domain 105A may include any number of content NEs and core NEs.

Domain 105B comprises NEs 113-114 and 120, of which NEs 113-114 may be content NEs 113-114 and NE 120 may be a core NE 120. Similarly, domain 105C comprises NEs 115-116 and 121, of which NEs 115-116 may be content NEs 115-116 and NE 121 may be a core NE 121. Domain 105D comprises NEs 117-118 and 122, of which NEs 117-118 may be content NEs 117-118 and NE 122 may be a core NE 122.

While the domain 105A is shown to include three content NEs 110-112 and one core NE 119, it should be appreciated that domain 105A may include any number of content NEs and core NEs. Similarly, while domains 105B-D are shown to include two content NEs 113-114, 115-116, and 117-118 and one

core NE

120, 121, and 122, respectively, it should be appreciated that domains 105B-D may include any number content NEs and core NEs. In addition, while only NEs 110-122 are shown as being coupled together by

interfaces

131 and 132, there may be other NEs between each of NEs 110-112.

Some of the domains 105A-D within the multi-domain network 100 may also comprise a classifier 125. A classifier 125 is typically a software module implemented by an ingress NE or an egress NE of a domain 105A-D that is configured determine whether a packet is an interest packet 166 or a data packet 177. An ingress NE is the NE in a domain 105A-D by which data is directly received from a consumer 103 or a producer 106. An ingress NE is the NE in a domain 105A-D by which data is directly transmitted to a consumer 103 or a producer 106. For example, the classifier 125 of domain 105A may be implemented by content NE 110, which may be the ingress NE of the domain 105A. Similarly, the classifier 125 of domain 105C may be implemented by content NE 116, which may be the ingress NE of the domain 105C.

To deliver content through a forwarding plane of the multi-domain network 100, a path 150 (shown in FIG. 1 as a bold dotted line) may be determined between the consumer 103 and the producer 106. The path 150 may be determined in a variety of different way based on a topology of the multi-domain network 100. For example, a controller that stores the network topology of the multi-domain network 100 may communicate with domain controllers for each of domains 105A-D to determine the path 150 between the consumer 103 and the producer 106.

As shown in FIG. 1, the path 150 may include content NE 110, core NE 119, content NE 112, content NE 113, core NE 120, content NE 114, content NE 115, core NE 121, and content NE 116 between the consumer 103 and the producer 106. In an embodiment, the content NE 110 may be an ingress content NE 110 that receives the interest packet 166 from the consumer 103 and transmits the data packet 177 to the consumer. The content NE 116 may be the egress content NE 116 that sends the interest packet 166 to the producer 106 and receives the data packet 177 from the producer 106. A description and identifier of the path 150 may be sent to the content NE 110, core NE 119, content NE 112, content NE 113, core NE 120, content NE 114, content NE 115, core NE 121, and content NE 116 as a forwarding rule that may be stored in an entry of the FIB in association with an identifier of the path 150.

In an embodiment, the interest packet 166 is sent by the consumer 103 to the producer 106 via the path 150 and is used to request a content object by a content name. For example, the interest packet 166 can identify content or a chunk of content to retrieve by providing a content name (also referred to as a name prefix) and other qualifications that define what data is acceptable from the collection named. The ingress content NE 110 may apply a longest name prefix matching (LPM) on the content name in the interest packet 166 using the FIB to determine the interface 132 over which to transmit the interest packet 166. The ingress content NE 110 may then transmit the interest packet 166 over interface 132 to the core NE 119. Similarly, the core NE 119 performs LPM on the content name described in the interest packet 166, and then transmits the interest packet over interface 132 to content NE 112. In the same way, content NE 112 performs LPM on the content name described in the interest packet 166, and then transmits the interest packet over interface 131 to content NE 113. In this way, the interest packet 116 is transmitted across content NE 110, core NE 119, content NE 112, content NE 113, core NE 120, content NE 114, content NE 115, core NE 121, and content NE 116 in multiple different domains 105A-C of the path 150.

At any point during transmission of the interest packet along path 150, one of content NEs 110 and 112-116, core NEs 119-121, or producer 106 may determine that the requested content named in the interest packet 166 is locally stored in the content store. When the interest packet 166 reaches a content NE 110 and 112-116, core NEs 119-121, or producer 106 that has the requested content, a data packet 177 comprising a content object (e.g., the content and the content name) is generated and returned back to the consumer 103 along the same path 150 traveled by the interest packet 166.

This return path 150 is based on state information set up by content NEs 110 and 112-116 and core NEs 119-211 that forwarded the corresponding interest packet 166. The content NEs 110 and 112-116 and core NEs 119-211 within the multi-domain network 100 keep both interest packets 116 and data packets 177 for a period of time. When a content NE 110 and 112-116 or core NE 119-121 receives multiple interest packets 166 for the same content, the content NEs A-D 110 and 112-116 or core NE 119-121 forwards only the first interest packet 166 received towards the content producer 106.

Typically, interest packets 166 and data packets 177 are transmitted through the multi-domain network 100 without securing the data that is being transmitted in the interest packet 166 and data packet 177. For example, an interest packet 166 comprising a name of the requested content may be transmitted through multiple domains 105A-C along the path 150 before reaching the producer 106 of the requested content. NEs 110, 112-116, and 119-121 within each of these domains 105A-C along the path 150 are typically able to inspect the interest packet 166 and process the interest packet 166 without any restriction. Similarly, a data packet 177 comprising the requested content is also transmitted through multiple domains 105A-C along the path 150 before reaching the consumer 103 that requested the content. NEs 110, 112-116, and 119-121 within each of these domains 105A-C are also able to inspect the data packet 177 and process the data packet 177, for example, by storing the content locally before forwarding the content to the consumer 103.

However, consumers 103 and producers 106 may want to prevent NEs 110-122 within particular untrusted domains 105A-D from being capable of inspecting and processing the data within the interest packets 166 and data packets 177. For example, consumers 103 may not want third party devices within an untrusted domain 105A-D to have knowledge of the content being requested by the interest packets 166. Similarly, producers 106 may not want third party devices within an untrusted domain 105A-D to be able to access or locally cache content originating from the producer 106.

The embodiments of this present disclosure are directed to methods and apparatuses that facilitate securing the interest packets 166 and the data packets 177 such that NEs 110-122 within an untrusted domain 105A-D may not inspect or process the data within the interest packets 166 and data packets 177. In an embodiment, a producer 106 may determine which of the domains 105A-D in a multi-domain network 100 are trusted domains 105A, C, and D, and which of the domains are untrusted domains 105B. The producer 106 may generate trust enforcement data based on the domains 105A, C, and D that are identified as trusted. The trust enforcement data may include a list of identifiers identifying a plurality of trusted domains 105A, C, and D within the multi-domain network 100.

In an embodiment, interest packets 166 and data packets 177 may be modified to include the trust enforcement data. When an NE 110, 112-116, and 119-121 on the path 150 within a domain 105A-C receives the interest packet 166 or the data packet 177, the NE 110, 112-116, and 119-121 may determine whether to process the interest packet 166 or the data packet 177 based on whether the domain 105A-C is identified in the trust enforcement data. An NE 113-114 and 120 within an untrusted domain 105B is not permitted to inspect and process the interest packet 166 or the data packet 177. In this case, the NE 113-114 and 120 simply forwards the interest packet 166 or the data packet 177 to the next hop based on a forwarding label of the interest packet 166 or the data packet 177. An NE 110-111, 115-116, 119, and 121 within a trusted domain 105A and C on path 150 is permitted to inspect and process the interest packet 166 or the data packet 177. In this case, the NE 110-111, 115-116, 119, and 121 may check the PIT and perform standard name based processing and routing on the interest packet 166 or data packet 177.

FIG. 2 is a diagram of an embodiment of an NE 200 in the multi-domain network 100 according to various embodiments of the disclosure. NE 200 may be implemented as any one of the NEs 110-122, consumer 103, or producer 106. The NE 200 may be configured to implement and/or support the trust enforcement routing mechanisms described herein. The NE 200 may be implemented in a single node or the functionality of NE 200 may be implemented in a plurality of nodes. One skilled in the art will recognize that the term NE encompasses a broad range of devices of which NE 200 is merely an example. The NE 200 is included for purposes of clarity of discussion, but is in no way meant to limit the application of the present disclosure to a particular NE embodiment or class of NE embodiments. At least some of the features and/or methods described in the disclosure may be implemented in a network apparatus or module such as NE 200. For instance, the features and/or methods in the disclosure may be implemented using hardware, firmware, and/or software installed to run on hardware. As shown in FIG. 2, the NE 200 comprises one or more ingress ports 210 and a receiver unit (Rx) 220 for receiving data, at least one processor, logic unit, or central processing unit (CPU) 230 to process the data, transmitter unit (Tx) 225 and one or more egress ports 250 for transmitting the data, and a memory 240 for storing the data.

The processor 230 may comprise one or more multi-core processors and be coupled to a memory 240, which may function as data stores, buffers, etc. The processor 230 may be implemented as a general processor or may be part of one or more application specific integrated circuits (ASICs) and/or digital signal processors (DSPs) . The processor 230 may comprise a trust enforcement module 260, which may perform processing functions of the content NEs 110-122, consumer 103, or the producer 106, as discussed more fully below. The trust enforcement module 260 may also be configured to perform the steps of methods 300-1300, and/or any other method discussed herein. The inclusion of the trust enforcement module 260 and associated methods and systems provide improvements to the functionality of the NE 200. Further, the trust enforcement module 260 effects a transformation of a particular article (e.g., the network) to a different state. In an alternative embodiment, trust enforcement module 260 may be implemented as instructions stored in the memory 240, which may be executed by the processor 230.

The memory 240 may comprise a cache for temporarily storing content, e.g., a random-access memory (RAM) . Additionally, the memory 240 may comprise a long-term storage for storing content relatively longer, e.g., a read-only memory (ROM) . For instance, the cache and the long-term storage may include dynamic RAMs (DRAMs) , solid-state drives (SSDs) , hard disks, or combinations thereof. The memory 240 may be configured to store trust enforcement data 270, which may include a list 280 of trusted domains 105A-D, keys 285 of trusted domains 105A-D, and a signature 290 of the producer 106. The list 280 of trusted domains 105A-D may comprise a list of identifiers identifying each of the domains 105A-D in the multi-domain network 100 that are determined to be trusted by a producer 106. The keys 285 are keys for each of the trusted domains 105A-D (e.g., public keys 285 or private keys 285) . For example, data within an interest packet 166 or data packet 177 may be encrypted using a public key 285 of a next trusted domain 105 on a path 150. When the interest packet 166 or data packet 177 reaches the next trusted domain 105 on the path 150, a NE 200 in the current trusted domain 105 may decrypt the data using the private key 285 of the current trusted domain 105. The keys 285 included in the interest packet 166 or the data packet 177 may be the whole public key 285 or a hash of the public key 285. If the hash of the public key 285 is included, then other domains 105 may have a mechanism by which to retrieve the whole public key 285 using the hash. Including a hash of the public key 285 instead of the whole public key 285 may be beneficial in reducing the overhead of both the interest packet 166 and the data packet 177. The signature 290 of the producer 106 may be a certificate or a digital signature that is sent with certain content from the producer 106 to verify the authenticity of the content.

It is understood that by programming and/or loading executable instructions onto the NE 200, at least one of the processor 230 and/or memory 240 are changed, transforming the NE 200 in part into a particular machine or apparatus, e.g., a multi-core forwarding architecture, having the novel functionality taught by the present disclosure. It is fundamental to the electrical engineering and software engineering arts that functionality that can be implemented by loading executable software into a computer can be converted to a hardware implementation by well-known design rules. Decisions between implementing a concept in software versus hardware typically hinge on considerations of stability of the design and numbers of units to be produced rather than any issues involved in translating from the software domain to the hardware domain. Generally, a design that is still subject to frequent change may be preferred to be implemented in software, because re-spinning a hardware implementation is more expensive than re-spinning a software design. Generally, a design that is stable that will be produced in large volume may be preferred to be implemented in hardware, for example in an ASIC, because for large production runs the hardware implementation may be less expensive than the software implementation. Often a design may be developed and tested in a software form and later transformed, by well-known design rules, to an equivalent hardware implementation in an ASIC that hardwires the instructions of the software. In the same manner as a machine controlled by a new ASIC in a particular machine or apparatus, likewise a computer that has been programmed and/or loaded with executable instructions may be viewed as a particular machine or apparatus.

FIGS. 3A-D are message sequences diagrams 300A-D illustrating an example of how to implement and enforce trust enforcement data 270 in the multi-domain network 100 according to various embodiments of the disclosure. FIGS. 3A-B illustrate an example of how to implement and enforce the trust enforcement data 270 when transmitting interest packets 166 across the multi-domain network 100. FIGS. 3C-D illustrate an example of how to implement and enforce the trust enforcement data 270 when transmitting data packets 177 across the multi-domain network 100.

As shown in FIG. 3A, at step 303, the consumer 103 transmits an initial interest packet 166 comprising a content name 304 to a producer 106. The content name 304 may include a name of a content object requested by the consumer 103. In an embodiment, the content name 304 may be encrypted such that only the producer 106 is capable of decrypting the content name 304 in the initial interest packet 166. For example, the trust enforcement module 260 of the consumer 103 may be executed by the consumer 103 to encrypt the content name 304 of the initial interest packet 166.

In an embodiment, the initial interest packet 166 may be a request for a manifest 310 associated with the content name 304. A manifest 310 may include information that describes a content object associated with the content name 304. For example, a manifest 310 may describe content chunks that are associated with the content object identified by the content name 304. The manifest 310 may also describe the different encoding formats that may be used to reproduce the content at the consumer 103.

In an embodiment, the manifest 310 may include trust enforcement data 270 for a requested content object for the consumer 103. In an embodiment, the trust enforcement data 270 includes the list 280 of identifiers identifying the trusted domains 105A-D for a particular requested content object associated with the content name 304 and the consumer 103. As described above with reference to FIG. 2, the trust enforcement data 270 may also include the public keys 285 for each of the trusted domains 105A-D and a signature 290 of the producer 106.

The initial interest packet 166 may travel along path 150 through domain 105A-C, as described above with reference to FIG. 1, until the initial interest packet 166 reaches the producer 106. At step 306, the producer 106 may determine the trusted domains 105A-D for the content object associated with the content name 304 included in the initial interest packet 166. As described above with reference to FIG. 1, the domains 105A-D in the multi-domain network 100 that are trusted may be domains 105A, C, and D. Domain 105B may be determined to be an untrusted domain.

In an embodiment, an NE 110, 112-116, and 119-121 within each of the domains 105A-C on the path 150 may append an identifier of the respective domain 105A-C to the end of the initial interest packet 166. The producer 106 may retrieve, or extract the identifiers of the domains 105A-C from the initial interest packet 166 and determine that only domains 105A and C are trusted within the multi-domain network 100. The producer 106 may generate the list 280 of trusted domains 105A and C based on the identifiers of the domains 105A-C appended onto the initial interest packet 166 and the pre-determined list of trusted domains 105A, C, and D. An example of how the producer 106 generates the list 280 of identifiers identifying the trusted domains 105A-D is further described below with reference to FIG. 4.

The producer 106 may also obtain the manifest 310 for the content object associated with the content name 304 included in the initial interest packet 166. In an embodiment, the producer 106 may generate the manifest 310 for the content object associated with the content name 304 included in the initial interest packet 166. In an embodiment, the producer 106 may retrieve the manifest 310 for the content object from a memory store of the producer 106. In this case, the manifest 310 may already be pre-generated for that particular content object.

At step 309, a data packet 177 comprising the manifest 310 and the trust enforcement data 270 may be transmitted back to the consumer 103 via domains 105A-C. In an embodiment, the manifest 310 and the trust enforcement data 270 may be encrypted using a public key 285 of the consumer and/or a public key 285 of one of the trusted domains 105A and C.

At step 311, the consumer 103 sends another interest packet 166 to the producer 106 via path 150. This interest packet 166 may include a content name 304 based on the manifest 310 received from the producer 106. In an embodiment, the consumer 103 encrypts the content name 304 within the interest packet 166. For example, the content name 304 may be encrypted using a public key 285 of the next trusted domain 105B. In an embodiment, the interest packet 166 also includes the trust enforcement data 270, which includes the list 280 of the trusted domains 105A and C on the path 150. In an embodiment, the list 280 comprises an identifier of the trusted domain 105A and an identifier of the trusted domain 105C. In an embodiment, the trust enforcement data 270 may also include keys 285 for each of the trusted domains 105A and C on the path 150.

As shown by step 311, the consumer 103 sends the interest packet 166 to an NE in domain 105A, such as content NE 110. This content NE 110 may be an ingress NE and a border NE for domain 105A. At step 312, the NE in domain 105A may determine whether domain 105A is identified in the trust enforcement data 270. For example, the NE in domain 105A checks the list 280 of trusted domains 105A and C on the path 150 to determine that the domain 105A is identified in the list 280 of trusted domains 105A and C.

In response to determining that domain 105A is identified in the trust enforcement data 270, at step 314, the NE in domain 105A proceeds to process the interest packet 166. In an embodiment, the interest packet 166 is processed by first decrypting the content name 304 within the interest packet 166 using the private key 285 of domain 105A. In an embodiment, the domain 105A determines that the interest packet 166 is to be name based forwarded using the name in the forwarding label of the interest packet 166. In an embodiment, the interest packet 166 is processed using the PIT, as described above with reference to FIG. 1.

If the content object associated with the content name 304 is not stored locally in a content store of the NE in domain 105A, then, at step 316, the interest packet 166 comprising the content name 304 and the trust enforcement data 270 is encrypted using a public key 285 of the next trusted domain 105C and forwarded along the next hops (e.g., core NE 119 and content NE 112) until it reaches an NE in domain 105B, as will be further described below with reference to FIGS. 7-9. The NE in domain 105B may be content NE 113, which may be an ingress and border NE of domain 105B.

Proceeding to FIG. 3B, the message sequence diagram 300B continues with step 318, in which the NE in domain 105B determines whether domain 105B is identified in the trust enforcement data 270. For example, the NE in domain 105B checks the list 280 of trusted domains 105A and C on the path 150 to determine that the domain 105B is not identified in the list 270 of trusted domains 105A and C.

In response to determining that domain 105B is not identified in the trust enforcement data 270, at step 320, the NE in domain 105B accesses the FIB to determine a next hop by which to transmit the interest packet 166 based on the forwarding label of the interest packet 166. The interest packet 166 is transmitted in this manner (e.g., by accessing the FIB) along the next hopes (e.g., core NE 120 and content NE 114) in domain 105B until the interest packet 166 reaches an NE in domain 105C. The NE in domain 105C may be content NE 115, which may be an ingress and border NE of domain 105C.

At step 322, the NE in domain 105C may determine whether domain 105C is identified in the trust enforcement data 270. For example, the NE in domain 105C checks the list 280 of trusted domains 105A and C on the path 150 to determine that the domain 105C is identified in the list 280 of trusted domains 105A and C.

In response to determining that domain 105C is identified in the trust enforcement data 270, at step 324, the NE in domain 105C proceeds to process the interest packet 166. In an embodiment, the interest packet 166 is processed by first decrypting the content name 304 within the interest packet 166 using the private key 285 of domain 105C. In an embodiment, the interest packet 166 is processed using the PIT, as described above with reference to FIG. 1.

If the content object associated with the content name 304 is not stored locally in a content store of the NE in domain 105C, then, at step 326, the interest packet 166 comprising the content name 304 and the trust enforcement data 270 is encrypted using a public key 285 of the producer 106 and forwarded along the next hops until it reaches the producer 106. At step 327, the producer 106 may obtain (e.g., retrieve from a content store of the producer 106) the content object associated with the content name 304 in the interest packet 166.

Proceeding to FIG. 3C, the message sequence diagram 300C continues with step 328, in which the producer 106 generates the data packet 177 comprising the content object 330 and the trust enforcement data 270 and transmits the data packet 177 along the path 150 in the return direction to the NE in domain 105C. Similar to step 322, at step 331, the NE in domain 105C may determine whether domain 105C is identified in the trust enforcement data 270.

Similar to step 324, at step 332, in response to determining that domain 105C is identified in the trust enforcement data 270, the NE in domain 105C proceeds to process the data packet 177. In an embodiment, the data packet 177 is processed by first decrypting the content name 304 that may also be within the data packet 177 using the private key 285 of domain 105C. The NE in domain 105C may compare the content name 304 and the trust enforcement data 270 with entries in the PIT to determine the consumers 103 that are to receive data packet 177.

At step 334, the NE in domain 105C encrypts the content object 330 using a key 285 of the next trusted domain 105A and forwards to the data packet 177 along the next hops of the path 150 until the data packet 177 reaches an NE in domain 105B. Similar to step 318, at step 336, the NE in domain 105B determines whether domain 105B is identified in the trust enforcement data 270. As described above, domain 105B is not identified in the list 270 of trusted domains 105A and C of the trust enforcement data 270.

Proceeding to FIG. 3D, the message sequence diagram 300D continues with step 338, in which the NE in domain 105B forwards the data packet 177 to the next hops along the path 150 until the data packet 177 reaches the NE in domain 105A. The content object 330 remains encrypted using the public key 285 of the trusted domain 105A while being transmitted through the untrusted domain 105B.

Similar to step 312, at step 340, the NE in domain 105A may determine whether domain 105A is identified in the trust enforcement data 270. Similar to step 314, at step 342, the NE in domain 105A proceeds to process the data packet 177 by first decrypting the content object 330 within the data packet 177 and checking the PIT for any other entries corresponding to the same content object 330 and the same trust enforcement data 270.

At step 344, the NE in domain 105A transmits the data packet 177 with the content object 330 and the trust enforcement data 270 back to the requesting consumer 103. Since the consumer 103 is trusted, the content object 330 may remain in a decrypted state when the content NE 110 directly transmits the data packet 177 to the consumer 103. However, when other intermediary nodes that may not be trusted are present between the content NE 110 and the consumer 103, the content object 330 may be encrypted before transmitting back to the consumer 103.

FIG. 4 is a diagram illustrating a method 400 of identifying the trusted domains 105A and C for the path 150 within the multi-domain network 100 for the consumer 103 according to various embodiments of the disclosure. Similar to step 303 described above with reference to FIG. 3A, the consumer 103 may send an initial interest packet 166 to the producer 106 via path 150. The initial interest packet 166 may be a request for a manifest 310 associated with the content name or service name included in the initial interest packet 166. In an embodiment, the content name in the initial interest packet 166 may be encrypted using a public key 285 of the service. The initial interest packet 166 may comprise a forwarding label 403, a name of interest 406, and the content name 304.

In an embodiment, the forwarding label 403 carries an identifier of a trusted domain 105A or C. Further details of how the forwarding label 403 is used for routing through a multi-domain network 100 is described in U.S. Patent No. 9,246,803, by Ravishankar Ravindran, et. al., dated January 26, 2016. The service name may also be included in a forwarding label 403 of the packet.

In an embodiment, a name of interest 406 is another name that is used by an NE 110-122 to access the FIB and determine a next hop for the initial interest packet 166. For example, the name of interest 406 may be a name of a service associated with the producer 106, such as, “/netflix/manifest/service<nonce>. ” An NE 110, 112-116, and 119-121 may find an entry in the FIB corresponding to this name of interest 406 to determine a next hop for the initial interest packet 166.

In an embodiment, the consumer 103 may encrypt the content name 304 with a public key 285 of the producer 106. The encryption of the content name 304 is shown in FIG. 4 by shading the box for the content name 304.

In an embodiment, the initial interest packet 166 travels along the path 150 through domains 150A-C until the initial interest packet 166 reaches the producer 106. An NE 110, 112-116, and 119-121 within each of the domains 105A-C on the path 150 may append an identifier of the respective domain 105A-C to the end of the initial interest packet 166. For example,

NE

110 or 112 may append an identifier of the domain 105A to the initial interest packet 166,

NE

113 or 114 may append an identifier of the domain 105B to the initial interest packet 166, and

NE

115 or 116 may append an identifier of the domain 105C to the initial interest packet 166. The initial interest packet 166 including the identifiers of the domain 105A-C may be transmitted to the producer 106.

In response to receiving the initial interest packet 166, the producer 106 may retrieve, or extract the identifiers of the domains 105A-C from the initial interest packet 166. The producer 106 may determine that only domains 105A and C are trusted within the multi-domain network 100. For example, the producer 106 is configured to filter the domains 105A-C to determine the trusted domains 105A and C. The producer 106 may generate the list 280 of trusted domains 105A and C based on the identifiers of the domains 105A-C appended onto the initial interest packet 166 and the pre-determined list of trusted domains 105A, C, and D. Subsequent to determining the trusted domains 105A and C in the multi-domain network 100, the producer 106 may generate the data packet 177 (with manifest 310) . This data packet 177 comprises the content name 304, a type field 409 indicating that this data packet 177 carries the manifest 310, the manifest 310, and the trust enforcement data 270.

As shown by the shading of the boxes for the content name 304, the type field 409, and the manifest 310, the content name 304, the type field 409, and the manifest 310 may be encrypted by the producer 106 with a public key 285 of the consumer 103 before being transmitted. In this way, none of the NEs 110-122 in the multi-domain network 100 except for the consumer 103 and the producer 106 may access the content name 304, the type field 409, and the manifest 310 within the data packet 177.

The trust enforcement data 270 includes the list 280 of trusted domains 105A and C and the keys 285 of the trusted domains 105A and C. As shown in FIG. 4, the list 280 includes an identifier 415A of the trusted domain 105A and an identifier 415C of domain 105C.

FIG. 5 is a diagram illustrating a method 500 of processing the interest packet 166 at a content NE 110 of the multi-domain network 100 according to various embodiments of the disclosure. The interest packet 166 shown in FIG. 5 may be an interest packet 166 that is sent by the consumer 103 subsequent to the consumer 103 receiving the manifest 310 from the producer 106, as described above with reference to FIG. 4. After the consumer 103 receives the trust enforcement data 270 with the manifest 310, then the consumer 103 may send interest packets 166 with the trust enforcement data 270.

As shown in FIG. 5, a memory 240 of an NE 110, 112-116, and 119-121 on the path 150 may include a PIT 503, a FIB 506, and a content store 509. As described above, the PIT 503, FIB 506, and the content store 509 are data structures storing data that is used for name based forwarding of interest packets 166 and data packets 177 through the multi-domain network 100.

The interest packet 166 shown in FIG. 5 includes the identifier offset (shown as ID offset in FIG. 5) 550. The identifier offset 550 may define an offset between the forwarding label 403 and the identifier 415A or C of the current or next trusted domain 105A or C. For example, the offset between the forwarding label 403 and the identifier 415A or C of the current or next trusted domain 105A or C may be a number of bits or bytes from the end of the forwarding label 403 and a beginning of the identifier 415A or C. As described above, the forwarding label 403 may carry the identifier 415A or C of the current or next trusted domain 105A or C.

As shown in FIG. 5, the consumer 103 may transmit the interest packet 166 to the ingress content NE 110 of domain 105A. The ingress content NE 110 of domain 105A may first execute the classifier 125 to determine information regarding the interest packet 166. The classifier 125 may determine whether the packet received from the consumer 103 is an interest packet 166 or a data packet 177. In an embodiment, the classifier 125 may also determine whether the interest packet 166 received from the consumer 103 should be trust enforced based on whether the interest packet 166 carries trust enforcement data 270.

In response to determining that the interest packet 166 carries trust enforcement data 270, at arrow 520, the classifier 125 may transmit the interest packet 166 to the trust enforcement module 260. The trust enforcement module 260 may be executed to enforce the trust enforcement data 270 in the interest packet 166. In an embodiment, the trust enforcement module 260 may determine whether the domain 105A is identified in the trust enforcement data 270.

At arrow 523, in response to determining that the domain 105A is identified in the trust enforcement data 270, the trust enforcement module 260 proceeds with the standard ICN processing of the interest packet 166. For example, a lookup may be performed on the PIT 503 to determine whether an entry for the content name 304 and the trust enforcement data 270 already exists in the PIT 503. A new entry for the content name 304 and the trust enforcement data 270 may be created if no such entry already exists. The content store 509 may also be searched to determine whether the content object 330 associated with the content name 304 in the interest packet 166 is locally cached. If the content store 509 does not locally store the content object 330, then the method 500 may continue by accessing the FIB 506 to determine the next hop 510 for the interest packet 166. For example, a next hop 510 for the interest packet 166 may be stored at the FIB 506 in association with the name of interest 406. The interest packet 166 may then be transmitted to the next hop 510.

At arrow 526, in response to determining that a domain 105B is not identified in the trust enforcement data 270, the trust enforcement module 260 may perform a lookup on the FIB 506 to determine a next hop 510 for the interest packet 166. The content NE 110 may transmit the interest packet 166 directly to the next hop 510 without performing ICN processing on the interest packet 166.

In response to determining that the interest packet 166 does not include trust enforcement data 270, at arrow 529, the content NE 110 may perform a lookup on the FIB 506 to determine the next hop 510 for the interest packet 166. The content NE 110 may transmit the interest packet 166 directly to the next hop 510 without performing ICN processing on the interest packet 166.

FIG. 6 is a diagram illustrating a method 600 of processing the data packet 177 at a content NE 116 of the multi-domain network 100 according to various embodiments of the disclosure. Similar to the interest packet 166 described with reference to FIG. 5, the data packet 177 includes the forwarding label 403, the identifier offset 550, the name of interest 406, the content name 304, and the trust enforcement data 270. However, the data packet 166 shown in FIG. 6 additionally includes the content object 330 associated with the content name 304 transmitted in the interest packet 166. As shown in FIG. 6, the content object 330 and the content name 304 may be encrypted using a public key 285 of either a next trusted domain 105A or C or a public key 285 of the consumer 103.

As shown in FIG. 6, the producer may transmit the data packet 177 to the ingress content NE 116 of domain 105C. The ingress content NE 116 of domain 105C may first execute the classifier 125 to determine information regarding the data packet 177, such as, whether the data packet 177 carries trust enforcement data 270.

In response to determining that the data packet 177 carries trust enforcement data 270, at arrow 620, the classifier 125 may transmit the data packet 177 to the trust enforcement module 260. The trust enforcement module 260 may be executed to enforce the trust enforcement data 270 in the data packet 177. In an embodiment, the trust enforcement module 260 may determine whether the domain 105C is identified in the trust enforcement data 270.

In response to determining that the domain 105C is identified in the trust enforcement data 270, at arrow 623, the trust enforcement module 260 proceeds with the standard ICN processing of the data packet 177. For example, a lookup may be performed on the PIT 503 to determine whether an entry for the content name 304 and the trust enforcement data 270 already exists in the PIT 503. The content object 330 may also be locally stored at the content store 509. Standard ICN processing for the data packet 177 is described above with reference to FIG. 1 and will be further described below with reference to FIGS. 10-12.

At arrow 626, in response to determining that a domain 105B is not identified in the trust enforcement data 270, the trust enforcement module 260 may perform a lookup on the FIB 506 to determine a next hop 610 for the data packet 177. For example, a next hop 610 for the data packet 177 may be stored at the FIB 506 in association with the name of interest 406. The content NE 116 may transmit the data packet 177 directly to the next hop 616 without performing ICN processing on the data packet 177.

At arrow 629, in response to determining that the data packet 177 does not include trust enforcement data 270, the content NE 110 may perform a lookup on the FIB 506 to determine a next hop 610 for the data packet 177. The content NE 110 may transmit the data packet 177 directly to the next hop 610 without performing ICN processing on the data packet 177.

FIGS. 7-12 are flowcharts illustrating methods 700-1200 of processing interest packets 166 and data packets 177 in the multi-domain network 100. In particular, FIGS. 7-9 are flowcharts illustrating methods 700-900 for processing interest packets 166 in the multi-domain network 100. Method 700 may be implemented by in an ingress border content NE 110, method 800 may be implemented by a core NE 119, and method 900 may be implemented by an egress border content NE 112. FIGS. 10-12 are flowcharts illustrating methods 1000-1200 for processing data packets 177 in the multi-domain network 100. Method 1000 may be implemented by in an ingress border content NE 116, method 1100 may be implemented by a core NE 121, and method 1200 may be implemented by an egress border content NE 115.

FIGS. 7A-B are flowcharts illustrating a method 700A-B of processing an interest packet 166 at an ingress border content NE 110 of domain 105A within the multi-domain network 100 according to various embodiments of the disclosure. For example, method 700A-B may be implemented by the ingress border content NE 110 after receiving the interest packet 166 from a consumer 103 or another content NE 110-116. Method 700A-B may be implemented by any of the ingress

border content NEs

110, 111, 113, 115, and 117.

Method 700A shown in FIG. 7A begins at step 703, in which a determination is made as to whether the interest packet 166 should be classified as a regular interest packet 166 or an interest packet 166 that is to be trust enforced. In an embodiment, the classifier 125 determines whether the interest packet 166 should be classified as a regular interest packet 166 or an interest packet 166 that is to be trust enforced based on whether trust enforcement data 270 is carried in the interest packet 166.

At step 706, in response to determining that the interest packet 166 should be classified as a regular interest packet 166, the interest packet 166 may be processed using standard ICN processing (e.g., by accessing the PIT 503 and the content store 509) . In response to determining that the interest packet 166 should be classified as one that is to be trust enforced, at step 709, a determination is made as to whether an identifier 415A or C of one of the trusted domains 105A or C is included in the forwarding label 403 of the interest packet 166.

In response to determining that an identifier 415A or C of one of the trusted domains 105A or C is not included in the forwarding label 403 of the interest packet 166, at step 711, the interest packet 166 may be dropped or discarded.

In response to determining that an identifier 415A or C of one of the trusted domains 105A or C is included in the forwarding label 403 of the interest packet 166, at step 713, a determination is made as to whether an identifier 415A of the current domain 105A is included in the trust enforcement data 270. In an embodiment, the ingress content NE 110 may use the identifier offset 550 to directly access the identifier 415A of the current domain 105A in the trust enforcement data 270. In an embodiment, the ingress content NE 110 may search through the list 280 in the trust enforcement data 270 to find the identifier 415A of the current domain 105A.

A determination that the identifier 415A of the current domain 105A is not included in the trust enforcement data 270 may be made. In this case, at step 715, the interest packet 166 may be forwarded to the next hop 510 using the FIB 506. In this step, standard ICN processing using the PIT 503 and the content store 509 is not performed on the interest packet 166.

In response to determining that the identifier 415A of the current domain 105A is included in the trust enforcement data 270, standard ICN processing using the PIT 503 and the content store 509 is performed on the interest packet 166. At step 718, the interest packet 166 may be decrypted using the private key 285 of the domain 105A. After decrypting the interest packet 166, at step 721, the signature 290 of the producer 106 may be validated by the ingress content NE 110 when the signature 290 is included in the trust enforcement data 270.

After decrypting and validating the interest packet 166, at step 723, a determination is made as to whether the PIT 503 includes an entry for the same content name 304 included in the interest packet 166 and the same trust enforcement data 270 included in the interest packet 166. In response to determining that the PIT 503 includes an entry for the same content name 304 included in the interest packet 166 and the same trust enforcement data 270 included in the interest packet 166, at step 726, data from the interest packet 166 may be added to the entry.

Unlike standard PIT 503 entries that are aggregated only based on common content names 304, the PIT 503 entries described herein are aggregated based on common content names 304 and common trust enforcement data 270. Data from interest packets 166 with common content names 304 but different trust enforcement data 270 may not be aggregated together in an entry of the PIT 503. In the case that the PIT 503 does not include an entry for the same content name 304 included in the interest packet 166 and the same trust enforcement data 270 included in the interest packet 166, at step 729, the content NE 110 may create an entry in the PIT 503 for the content name 304 and the trust enforcement data 270.

Proceeding to method 700B shown in FIG. 7B, after the entry for the content name 304 and the trust enforcement data 270 is created in the PIT 503, at step 731, a determination is made as to whether the content object 330 is locally stored in the content store 509 of the content NE 110. The locally stored the content object 330 may be associated with the same trust enforcement data 270 as that included in the interest packet 166. In response to determining that the content object 330 is locally stored in the content store 509 of the content NE 110, at step 733, the content object 330 may be returned to the consumer 103 over path 150 in the return direction. In response to determining that the content object 330 is not locally stored in the content store 509 of the content NE 110, at step 736, the forwarding label 403 is removed from the interest packet 166. The content NE 110 then forwards the NE to the next NE on the path 150, which is the core NE 119.

FIG. 8 is a flowchart illustrating a method 800 of processing an interest packet 166 at a core NE 119 of a domain 105A within the multi-domain network 100 according to various embodiments of the disclosure. Method 800 is implemented by any of the core NEs 119-122 after receiving the interest packet 166 from a content NE, such as content NE 110.

At step 803, a determination is made as to whether the interest packet 166 should be classified as a regular interest packet 166 or an interest packet 166 that is to be trust enforced, similar to step 703. In response to determining that the interest packet 166 should be classified as a regular interest packet 166, at step 806, the interest packet 166 may be processed using standard ICN processing (e.g., by accessing the PIT 503 and the content store 509) . In response to determining that the interest packet 166 should be classified as one that is to be trust enforced, at step 809, a determination is made as to whether an identifier 415A or C of one of the trusted domains 105A or C is included in the forwarding label 403 of the interest packet 166.

As described above with reference to step 736, the ingress content NE 110 removed the identifier 415A of the domain 105A from the forwarding label 403 after processing an interest packet 166 with trust enforcement data 270. Therefore, when the core NE 119 receives an interest packet 166 without the identifier 415A of the domain 105A in the forwarding label 403, the core NE 119 may immediately determine that the interest packet 166 contains trust enforcement data 270 that should be enforced accordingly. In this way, when the identifier 415A of the domain 105A is not in the forwarding label 403, at step 811, the core NE 119 may perform standard ICN processing on the interest packet 166 using the PIT 503 and the content store 509. In contrast, when the identifier 415A of the domain 105A is in the forwarding label 403, at step 813, the core NE 119 may forward the interest packet 166 to the next hop 510 on the path 150 using the FIB 506, without performing an ICN processing using the PIT 503 and the content store 509.

FIG. 9 is a flowchart illustrating a method 900 of processing an interest packet 166 at an egress border content NE 112 of a domain 105A within the multi-domain network 100 according to various embodiments of the disclosure. Method 900 is implemented by any of the egress

border content NEs

112, 114, 116, and 118 after receiving the interest packet 166 from an NE, such as core NE 119.

At step 903, a determination is made as to whether the interest packet 166 should be classified as a regular interest packet 166 or an interest packet 166 that is to be trust enforced, similar to step 703. In response to determining that the interest packet 166 should be classified as a regular interest packet 166, at step 906, the interest packet 166 may be processed using standard ICN processing (e.g., by accessing the PIT 503 and the content store 509) . In response to determining that the interest packet 166 should be classified as one that is to be trust enforced, at step 909, a determination is made as to whether an identifier 415A or C of one of the trusted domains 105A or C is included in the forwarding label 403 of the interest packet 166.

A determination may be made that the identifier 415A of the domain 105A is in the forwarding label 403. In this case, at step 911, the content NE 112 may forward the interest packet 166 to the next hop 510 on the path 150 using the FIB 506, without performing an ICN processing using the PIT 503 and the content store 509.

In contrast, a determination may be made that the identifier 415A of the domain 105A is not in the forwarding label 403. In this case, at step 913, the content NE 112 may perform standard ICN processing on the interest packet 166 using the PIT 503 and the content store 509.

After performing standard ICN processing on the interest packet 166, at step 916, a determination is made as to whether a neighboring domain 105B is trusted. As described above, neighboring domain 105B is not trusted, and in this case, at step 919, the content NE 112 may encrypt the interest packet 166 with a public key 285 of the next trusted domain 105C, add an identifier 415C of the next trusted domain 105C to the forwarding label 403, and forward the interest packet 166 to the neighboring domain 105B.

However, supposing that the neighboring domain 105B is a trusted domain, the content NE 112 may skip the encryption process, and instead at step 921 simply add an identifier 415C of the next trusted domain 105B to the forwarding label 403 and forward the interest packet 166 to the neighboring domain 105B. The skipping of the encryption process when the neighboring domain 105B is trusted may save time and resources when transmitting data within the multi-domain network 100.

FIG. 10 is a flowchart of a method 1000 of processing a data packet 177 at an ingress border content NE 116 of domain 105C within the multi-domain network 100 according to various embodiments of the disclosure. For example, method 1000 is implemented by the ingress border content NE 116 after receiving the data packet 177 from a producer 106 or another content NE 110-116. Method 1000 may be implemented by any of the ingress

border content NEs

112, 111, 114, and 118.

At step 1003, a determination is made as to whether the data packet 177 should be classified as a regular data packet 177 or a data packet 177 that is to be trust enforced. In an embodiment, the classifier 125 determines whether the data packet 177 should be classified as a regular data packet 177 or a data packet 177 that is to be trust enforced. In an embodiment, a determination regarding whether to classify the data packet 177 as one that is to be trust enforced may be made based on whether trust enforcement data 270 is carried in the data packet 177.

A determination may be made that the data packet 177 is classified as a regular data packet 177. In this case, at step 1006, the data packet 177 may be processed using standard ICN processing (e.g., by accessing the PIT 503 and the content store 509) . For example, standard ICN processing of the data packet 177 may involve checking the PIT 503 for entries associated with the particular content object 330 in the data packet 177 that have the trust enforcement data 270, locally caching the content object 330 in the content store 509, and then typically transmitting the content object 330 to the consumers 103 identified in the entries.

In response to determining that the data packet 177 should be classified as one that is to be trust enforced, at step 1009, a determination is made as to whether an identifier 415A or C of one of the trusted domains 105A or C is included in the forwarding label 403 of the data packet 177. When it is determined that an identifier 415A or C of one of the trusted domains 105A or C is not included in the forwarding label 403 of the data packet 177, at step 1011, the data packet 177 may be dropped or discarded. In contrast, when it is determined that an identifier 415A or C of one of the trusted domains 105A or C is included in the forwarding label 403 of the data packet 177, at step 1013, a determination is made as to whether an identifier 415C of the current domain 105C is included in the trust enforcement data 270.

When the identifier 415A of the current domain 105C is not included in the trust enforcement data 270, at step 1015, the data packet 177 may be forwarded to the next hop 610 using the FIB 506. In this step, standard ICN processing using the PIT 503 and the content store 509 is not performed on the data packet 177.

In contrast, when the identifier 415A of the current domain 105C is not included in the trust enforcement data 270. In this case, at step 1018, standard ICN processing using the PIT 503 and the content store 509 is performed on the data packet 177. At step 1018, the data packet 177 may be decrypted using the private key 285 of the domain 105C. After decrypting the data packet 177, at step 1021, the signature 290 of the producer 106 may be validated by the ingress content NE 116 when the signature 290 is included in the trust enforcement data 270.

After decrypting and validating the data packet 177, at step 1023, a determination is made as to whether the PIT 503 includes an entry for the same content name 304 included in the data packet 177 and the same trust enforcement data 270 included in the data packet 177. In response to determining that the PIT 503 does not include an entry for the same content name 304 included in the interest packet 166 and the same trust enforcement data 270 included in the interest packet 166, at step 1026, the data packet 177 may be dropped or discarded because the interest for the content object 330 within the data packet 177 has expired.

In response to determining that the PIT 503 includes an entry for the same content name 304 included in the data packet 177 and the same trust enforcement data 270 included in the data packet 177, at step 1029, standard ICN processing may be performed on the data packet 177. First, the identifier 415C of domain 105C may be removed from the forwarding label 403 of the data packet 177. Then the data packet 177 may be forwarded to the next hop 610 based on the entry in the PIT 503 and/or the FIB 506. In addition, the content object 330 in the data packet 177 may be cached locally in the content store 509 of the content NE 116. In an embodiment, the entry may be removed from the PIT 503.

FIG. 11 is a flowchart illustrating a method 1100 of processing a data packet 177 at a core NE 121 of a domain 105C within the multi-domain network 100 according to various embodiments of the disclosure. Method 1100 is implemented by any of the core NEs 119-122 after receiving the interest packet 166 from a content NE, such as content NE 116.

At step 1103, a determination is made as to whether the data packet 177 should be classified as a regular data packet 177 or a data packet 177 that is to be trust enforced, similar to step 703. In response to determining that the data packet 177 should be classified as a regular data packet 177, at step 1106, the data packet 177 may be processed using standard ICN processing (e.g., by accessing the PIT 503 and the content store 509) . In response to determining that the data packet 177 should be classified as one that is to be trust enforced, at step 1109, a determination is made as to whether an identifier 415A or C of one of the trusted domains 105A or C is included in the forwarding label 403 of the data packet 177.

As described above with reference to step 1029, the ingress content NE 110 removes the identifier 415C of the domain 105C from the forwarding label 403 after processing a data packet 177 with trust enforcement data 270. Therefore, when the core NE 121 receives a data packet 177 without the identifier 415C of the domain 105C in the forwarding label 403, the core NE 121 may directly determine that the data packet 177 contains trust enforcement data 270 that should be enforced accordingly. In this way, in response to determining that the identifier 415C of the domain 105C is not in the forwarding label 403, at step 1111, the core NE 121 may perform standard ICN processing on the data packet 177 using the PIT 503 and the content store 509. In contrast, at step 1113, the core NE 121 may forward the data packet 177 to the next hop 610 on the path 150 using the FIB 506, without performing an ICN processing using the PIT 503 and the content store 509.

FIG. 12 is a flowchart illustrating a method 900 of processing a data packet 177 at a egress border content NE 115 of a domain 105C within the multi-domain network 100 according to various embodiments of the disclosure. Method 1200 is implemented by any of the egress

border content NEs

117, 115, 113, 110, and 111 after receiving the data packet 177 from an NE, such as core NE 121.

At step 1203, a determination is made as to whether the data packet 177 should be classified as a regular data packet 177 or a data packet 177 that is to be trust enforced, similar to step 703. In response to determining that the data packet 177 should be classified as a regular data packet 177, at step 1206, the data packet 177 may be processed using standard ICN processing (e.g., by accessing the PIT 503 and the content store 509) . In response to determining that the data packet 177 should be classified as one that is to be trust enforced, at step 1209, a determination is made as to whether an identifier 415A or C of one of the trusted domains 105A or C is included in the forwarding label 403 of the data packet 177.

A determination may be made that the identifier 415C of the domain 105C is in the forwarding label 403. At step 1211, the content NE 112 may forward the data packet 177 to the next hop 610 on the path 150 using the FIB 506, without performing an ICN processing using the PIT 503 and the content store 509.

In contrast, a determination may be made that the identifier 415C of the domain 105C is not in the forwarding label 403. In this case, at step 1213, the content NE 115 may perform standard ICN processing on the data packet 177 using the PIT 503 and the content store 509.

After performing standard ICN processing on the data packet 177, at step 1216, a determination is made as to whether a neighboring domain 105B is trusted. As described above, neighboring domain 105B is not trusted, and in this case, at step 1219, the content NE 115 may encrypt the data packet 177 with a public key 285 of the next trusted domain 105A, add an identifier 415A of the next trusted domain 105A to the forwarding label 403, and forward the data packet 177 to the neighboring domain 105B. However, supposing that the neighboring domain 105B is a trusted domain, the content NE 115 may skip the encryption process, and at step 1221 instead simply add an identifier 415 of the next trusted domain 105B to the forwarding label 403 and forward the data packet 177 to the neighboring domain 105B.

FIG. 13 is a flowchart illustrating a method 1300 for processing packets with trust enforcement data 270 within the multi-domain network 100 according to various embodiments of the disclosure. Method 1300 may be implemented by any of the NEs 110-122 when an interest packet 166 or a data packet 177 is received.

At step 1303, a packet comprising a content name 304 associated with a content object 330 and trust enforcement data 270 is received from a consumer 103. In an embodiment, Rx 220 of an NE 110-122 may receive the packet from the consumer 103. The packet may be an interest packet 166 or a data packet 177. The packet may be received directly from a consumer 103, a producer 106, or one of the NEs 110-122.

At step 1306, a determination is made as to whether to process the packet based on whether the domain 105A-D is identified in the list 280 of identifiers 415 identifying the plurality of trusted domains 105A, C, and D. For example, the trust enforcement module 260 may be executed by the processor 230 to determine whether to process the packet based on whether the domain 105A-D is identified in the list 280 of identifiers 415 identifying the plurality of trusted domains 105A, C, and D.

FIG. 14 is a diagram illustrating an apparatus 1400 for processing interest packets 166 and data packets 177 according to various embodiments of the disclosure. Apparatus 1400 comprises a means for receiving 1403 and a means for determining 1406. The means for receiving 1403 comprises a means to receive an interest packet 166 comprising a content name 304 associated with a content object 330 and trust enforcement data 270. The means for receiving 1403 may also comprise a means to receive a data packet 177 comprising the content object 330 and the trust enforcement data 270. The trust enforcement data 270 comprises the list 280 of identifiers 415 identifying a plurality of trusted domains 415A, C, and D within the multi-domain network 100.

FIG. 15 is a diagram illustrating an apparatus 1500 for processing interest packets 166 and data packets 177 according to various embodiments of the disclosure. Apparatus 1500 comprises a means for transmitting 1503 and a means for receiving 1506. The means for transmitting 1503 comprises a means to transmit an interest packet 166 comprising a content name 304 associated with a content object 330 to a producer 106. The means for receiving 1506 may comprise a means to receive a manifest 310 comprising information regarding the content object 330 and trust enforcement data 270. The trust enforcement data 270 comprises the list 280 of identifiers 415 identifying a plurality of trusted domains 415A, C, and D within the multi-domain network 100.

In an embodiment, the means for receiving 1506 may comprise a means to receive an interest packet 166 comprising a content name 304 associated with a content object 330 from a consumer 103. In an embodiment, the means for transmitting 1503 may comprise a means for transmitting a manifest 310 comprising information regarding the content object 330 and trust enforcement data 270. The trust enforcement data 270 comprises the list 280 of identifiers 415 identifying a plurality of trusted domains 415A, C, and D within the multi-domain network 100.

While several embodiments have been provided in the present disclosure, it should be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.

In addition, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. Other items shown or discussed as coupled may be directly coupled or may be indirectly coupled or communicating through some interface, device, or intermediate component whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made without departing from the spirit and scope disclosed herein.

Claims

A content network element (NE) implemented in a domain of a multi-domain network, comprising:

a receiver configured to receive an interest packet comprising a content name associated with a content object and trust enforcement data, the trust enforcement data comprising a list of identifiers identifying a plurality of trusted domains within the multi-domain network; and

a processor coupled to the receiver and configured to determine whether to process the interest packet based on whether the domain is identified in the list of identifiers identifying the plurality of trusted domains.
The content NE of claim 1, wherein the trust enforcement data further comprises a public key for each of the plurality of trusted domains.
The content NE of any one of claims 1 to 2, wherein the trust enforcement data further comprises a signature associated with a producer of the content object.
The content NE of any one of claims 1 to 3, further comprising a memory coupled to the processor and configured to store a pending interest table (PIT) , wherein the trust enforcement data comprises a signature of the producer, and wherein in response to determining that the domain is identified in the list of identifiers identifying the plurality of trusted domains, the processor is further configured to:

decrypt the interest packet using a private key associated with the domain;

validate the signature of the producer included in the trust enforcement data; and

create an entry in the PIT storing the content name in association with the trust enforcement data, wherein data associated with a plurality of interest messages including the content name and the trust enforcement data is aggregated together in the entry.
The content NE of any one of claims 1 to 4, further comprising a memory coupled to the processor and configured to store a content store, and wherein, in response to determining that the domain is identified in the list of identifiers identifying the plurality of trusted domains and determining that the content object is stored at the content store, a transmitter coupled to the processor is further configured to transmit the content object stored at the content store back to a consumer.
The content NE of any one of claims 1 to 5, further comprising a transmitter coupled to the processor, wherein the content name is encrypted within the interest packet, and wherein in response to determining that the domain is not identified in the list of identifiers identifying the plurality of trusted domains, the transmitter is configured to forward the interest packet to a next hop according to a forwarding label of the interest packet and a forwarding information database (FIB) of the content NE without inspecting the interest packet.
The content NE of any one of claims 1 to 6, wherein the processor is further configured to generate an initial interest packet before receiving the interest packet, wherein an identifier of the domain is appended to the initial interest packet, wherein the content NE further comprises a transmitter coupled to the processor and configured to forward the initial interest packet to a next hop according to a forwarding label of the initial interest packet, wherein the receiver is further configured to receive a manifest comprising information regarding the content object and the trust enforcement data from a producer in response to transmitting the initial interest packet.
The content NE of any one of claims 1 to 7, wherein the processor is further configured to classify the interest packet as including trust enforcement data before determining whether to process the interest packet based on whether the domain is identified in the list of identifiers identifying the plurality of trusted domains.
A content network element (NE) implemented in a domain of a multi-domain network, comprising:

a receiver configured to receive a data packet comprising a content object and trust enforcement data, the trust enforcement data comprising a list of identifiers identifying a plurality of trusted domains within the multi-domain network; and

a processor coupled to the receiver and configured to determine whether to process the data packet based on whether the domain is identified in the list of identifiers identifying the plurality of trusted domains.
The content NE of claim 9, wherein the receiver is further configured to receive an interest packet comprising a content name associated with the content object and the trust enforcement data, and wherein the data packet is received from a producer of the content object after receiving the interest packet.
The content NE of any one of claims 9 to 10, wherein before receiving the data packet, the receiver is further configured to receive a manifest from a producer of the content object, the manifest comprising information regarding the content object and the trust enforcement data.
The content NE of any one of claims 9 to 11, further comprising a memory coupled to the processor and configured to store a pending interest table (PIT) , wherein the trust enforcement data further comprises a signature of a producer of the content object, wherein in response to determining that the domain is identified in the list of identifiers identifying the plurality of trusted domains, the processor is further configured to:

decrypt the data packet using a private key associated with at least one of the producer or the domain;

validate a signature included in the trust enforcement data; and

determine whether an entry for the content object exists in the PIT.
The content NE of claim 12, further comprising a memory coupled to the processor and configured to store a forwarding information database (FIB) and a content store, and wherein, in response to the entry for the content object exists in the PIT, the processor is further configured to:

delete the entry from the PIT;

remove a forwarding label from the data packet; and

cache the content object in association with the trust enforcement data in the content store, and

wherein the content NE further comprises a transmitter configured to transmit the content object to a consumer based on the PIT.
A method implemented by content network element (NE) in a domain of a multi-domain network comprising:

receiving, by a receiver of the content NE, a packet comprising a content name associated with a content object and trust enforcement data, the trust enforcement data comprising a list of identifiers identifying a plurality of trusted domains within the multi-domain network; and

determining, by a processor coupled to the receiver, whether to process the packet based on whether the domain is identified in the list of identifiers identifying the plurality of trusted domains.
The method of claim 14, wherein the packet is an interest packet received from a consumer requesting the content object from a producer.
The method of any one of claims 14 to 15, wherein the packet is a data packet received from a producer comprising the content object requested by a consumer.
The method of any one of claims 14 to 16, wherein the trust enforcement data further comprises a private key for each of the plurality of trusted domains.
The method of any one of claims 14 to 17, wherein the trust enforcement data further comprises a signature associated with a producer of the content object.
The method of any one of claims 14 to 18, wherein the packet is an interest packet received from a consumer requesting the content object, and wherein in response to determining that the domain is identified in the list of identifiers identifying the plurality of trusted domains, the method further comprises:

decrypt, by the processor, the interest packet using a private key associated with at least one of the producer or the domain;

create, by the processor, an entry in a pending interest table (PIT) storing the content name in association with the trust enforcement data; and

forward, by a transmitter coupled to the processor, the content object in response to determining that the content object is cached at the content NE.
The method of any one of claims 14 to 19, wherein the packet is a data packet comprising the content object received from a producer, and wherein the method further comprises:

forward, by a transmitter coupled to the processor, the content object to a consumer requesting the content object based on an entry for the content object in the pending interest table (PIT) ; and

cache, by a memory coupled to the processor, the content object locally at the content NE.
A consumer implemented in a multi-domain network, comprising:

a transmitter configured to transmit an interest packet comprising a content name associated with a content object to a producer; and

a receiver configured to receive a manifest comprising information regarding the content object and trust enforcement data from the producer, the trust enforcement data comprising a list of identifiers identifying a plurality of trusted domains within the multi-domain network.
The consumer of claim 21, further comprising a processor configured to encrypt a second interest packet comprising the content name and the trust enforcement data in response to determining that a neighboring domain is not identified in the trust enforcement data, wherein the transmitter is further configured to transmit the second interest packet to a border content network element (NE) of the neighboring domain.
The consumer of any one of claims 21 to 22, wherein the receiver is further configured to receive a data packet comprising the content object and the trust enforcement data.
A producer implemented in a multi-domain network, comprising:

a receiver configured to receive an interest packet comprising a content name associated with a content object from a consumer; and

a transmitter configured to transmit a manifest comprising information regarding the content object and trust enforcement data to the consumer, the trust enforcement data comprising a list of identifiers identifying a plurality of trusted domains within the multi-domain network.
The producer of claim 24, further comprising a processor configured to encrypt the manifest before transmitting the manifest and in response to determining that a neighboring domain is not identified in the trust enforcement data.
The producer of any one of claims 24 to 25, further comprising a processor configured to encrypt the content object before transmitting the content object to the consumer and in response to determining that a neighboring domain is not identified in the trust enforcement data.
The producer of any one of claims 24 to 26, further comprising a processor configured to:

extract identifiers of a plurality of domains through which an initial interest packet traveled;

determine a plurality of trusted domains from the plurality of domains through which the initial interest packet traveled; and

generate a list of trusted domains comprising the plurality of trusted domains.