WO2015112499A1 - Secure ad hoc group in an information-centric network - Google Patents
Secure ad hoc group in an information-centric network Download PDFInfo
- Publication number
- WO2015112499A1 WO2015112499A1 PCT/US2015/012049 US2015012049W WO2015112499A1 WO 2015112499 A1 WO2015112499 A1 WO 2015112499A1 US 2015012049 W US2015012049 W US 2015012049W WO 2015112499 A1 WO2015112499 A1 WO 2015112499A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- service
- name
- producer
- specified
- producer device
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
Definitions
- the present disclosure relates generally to an Information-centric Network (ICN) , and more specifically to Ad hoc group device-to-device communication in ICN.
- ICN Information-centric Network
- the ICN is currently well suited to enable customers and service producers to discover and exchange information, such as information in an ad hoc device-to-device (D2D) scenario.
- D2D device-to-device
- Zero-config like protocols do not consider ad hoc group security at all.
- Many discovery protocols are in the application (app) level, e.g., web services discovery, and not in an ad hoc network environment .
- a method comprises an application in a consumer device sending a discovery interest including an associated service name or prefix encrypted by an encryption key using the ICN.
- a producer device publishing and discovery protocol (SPDP) on an ICN stack of the producer device receives the discovery interest from the ICN and checks to see if there is a local published service that matches the service name or prefix in the discovery interest, and if so, verifies the consumer device using the encryption key.
- the producer device SPDP returns a data protocol data unit (PDU) to the consumer device configured to enable the consumer device to access the published service, and the consumer device establishes routing with the producer device and receives the local published service.
- PDU data protocol data unit
- a producer device is configured to enable the methodology.
- FIGURE 1 illustrates a block diagram of an ICN stack on a device
- FIGURE 2 illustrates 3 steps/phases to enable secure information exchange
- FIGURE 3 illustrates a block diagram of Phase-0 service publishing
- FIGURE 4A and 4B illustrate a block diagram of secure service discovery
- FIGURE 5 illustrates a block diagram of secure binding of a consumer and producer
- FIGURE 6 illustrates a block diagram of a secure group communication
- FIGURE 7 illustrates an embodiment of a network unit
- FIGURE 8 illustrates a typical, general-purpose network component .
- the present disclosure provides a system and methodology enabling both a secure discovery of information in an ICN, and a secure information exchange between devices on-demand in an ad hoc ICN scenario.
- a service publishing and a discovery utility such as a service publishing discovery protocol (SPDP) for service discovery
- SPDP service publishing discovery protocol
- Services are named and associated with policy requirements, e.g., which user or group can access a service. Routing is a result of service discovery.
- Each service that is discoverable to others has an identity credential. Without loss of generality, it is assumed that the identity credential is a public key (pbk) and private key (prk) pair (pbk/prk) , and the pbk is certified by some trust management mechanism such as an enterprise PKI .
- CA common certificate authority
- CA public key certificate
- Phase 1 is the secure service discovery whereby services can be discovered only by authorized consumers.
- Phase 2 secures binding between customers and producers, whereby service discovery causes a path to be set and binds the service to valid consumers.
- Phase 3 secures information exchange, and ensures the data itself is secured in terms or provenance, and integrity. Considering ad hoc, keys used for information exchange should be temporal in nature.
- the service publishing protocol is similar as before, with the addition of new fields in the service profile: [0019]
- the field ⁇ allowed_consumer> specifies a set of consumers or a group that is authorized to discovery and consume the service.
- xxx Hash(pbk_c), where pbk_c is the public key certificate associated with individual service/user/device;
- yyy Hash (pbk_ca) , where pubk_ca is the public key of a
- CA e.g., a company's enterprise CA
- phase 1 secure service discovery it is assumed that the service on a set of devices is affiliated to the same organization. In a general case, the device itself may not be trusted.
- the service can be a general network service or application, where users have pre-trust, e.g., a social application where the users are in each other's contact list.
- the credential such as a public key certificate
- a trust management mechanism e.g., a PKI
- Each service has the common CA's public key certificate (pbk_ca) , such that it can verify the signature (sig) signed from another service in an off-line manner. This can be setup during installation time of the service, or by IT admin of the device .
- Phase 1 Secure Service Discovery [0027] Referring to Fig. 4A and 4B, there is shown a preferred embodiment for secure service discovery.
- pbk_c is the public key of the consumer app
- the interest protocol data unit (PDU) on the consumer device is signed by prk_c;
- a timestamp or session token can be used to prevent replay attack in the discovery protocol
- a name-prefix can be included optionally and for filtering purposes, such as disclosed in the previously identified commonly assigned patent application.
- the discovery protocol reaches the SPDP on service producer ICN stack, such as disclosed in the previously identified commonly assigned patent application.
- the SPDP verifies the sig with pbk_c, and verifies pbk_c with pbk_ca, where pbk_ca is the public key of the CA.
- the SPDP returns a data PDU ⁇ random_name, Enc (service_profile, pbk_c))>, where: random_name is a pseduo-random name generated by the producer, time-to-live (TTL) can also be associated wi,th this entity; service_profile is the matched local published service, which includes the real service name;
- the service_profile is encrypted by the pbk_c .
- this service-response data PDU is returned to the consumer.
- the routing path is also set between the consumer and the service producer, such as described in the previously identified commonly assigned patent application, with the random_name as the name/prefix in FIB entries.
- service_name ⁇ > random_name mapping in its local database Each service on local device can read the random_name of its published service_name .
- the SPDP When a new discovery interest is received by the SPDP for the same service name, the SPDP first checks if there is a random_name for the service_profile available, if so it uses the random_name in the return data PDU, instead of generating a new random_name for the same service_profile .
- the ICN stack and all intermediate nodes have setup forwarding information base (FIB) entries to reach the producer from the consumer, with the random_name as entries, such as described in the previously identified commonly assigned patent application.
- FIB forwarding information base
- both the producer and the consumer have a valid mapping of (service_name ⁇ > random_name) . All intermediate nodes have random_name in their FIBs . The ICN network knows nothing about service_name since the service_profile is encrypted in the discovery phase.
- the app in the consumer side sends interest ⁇ random_name, pbk_c, sig> to communicate with the producer service, where the sig is a signature generated with prk_c .
- the service app checks local (service_name ⁇ > random_name) mapping, and obtains the corresponding service_name .
- the service app then generates the data payload, as usual application functions, and returns the data PDU ⁇ random_name, Enc (payload, pbk_c))>.
- the service app checks its local security policy if pbk_c is allowed to receive its data.
- pbk_c there can be many ways for using pbk_c to encrypt the data payload, e.g., http: //en.wikipedia. org/wiki/Key_encapsulation.
- Phase 3 Secure Group Communication
- the service producer SPDP first generates a symmetric group_session_key, and returns the data PDU ⁇ random_name, Enc (service_profile, group_session _key, pbk_c))>, where:
- random_name is a pseudo-random name generated by the producer
- service_profile is the matched local published service, which includes the real service name
- Group_session_key is a symmetric key (e.g., AES) for the group; and options may be available for using pbk_c to encrypt the service_profile and group_session_key.
- AES symmetric key
- Step 2.1 after receiving the data PDU ⁇ random_name, Enc (service_profile, group_session_key, pbk_c) ) >, the consumer app decrypts the data PDU with prk_c, and gets the service_profile and service_name . It then maintains a map of (service_name ⁇ > random_name ⁇ > group_session_key) .
- the random_name is used to bind the service and its consumers.
- the producer SPDP checks if there is local (service_name ⁇ > random_name ⁇ > group_session_key) . If so, it returns the data PDU ⁇ random_name, Enc (service_profile, group_session_key, pbk_c2)).
- the consumer 2 app decrypts the data PDU with prk_c2 and obtains the service profile and the service name, similar to the first consumer. This way, multiple interactive applications agree on the same random- name and group key.
- the same group key encrypted content can be cached in the network, and can use multicasting.
- the service checks its local security policy if pbk_c is allowed to receive its data.
- Fig. 7 illustrates an embodiment of a network unit 1000, which may be any device that transports and processes data through network 100.
- the network unit 1000 may correspond to or may be located in any of the system nodes described above, such as a M , PoA, content router R, and AS.
- the network unit 1000 may also be configured to implement or support the schemes and methods described above.
- the network unit 1000 may comprise one or more ingress ports or units 1010 coupled to a receiver (Rx) 1012 for receiving signals and frames/data from other network components.
- the network unit 1000 may comprise a content aware unit 1020 to determine which network components to send content to.
- the content aware unit 1020 may be implemented using hardware, software, or both.
- the network unit 1000 may also comprise one or more egress ports or units 1030 coupled to a transmitter (Tx) 1032 for transmitting signals and frames/data to the other network components.
- Tx transmitter
- the receiver 1012, content aware unit 1020, and transmitter 1032 may also be configured to implement at least some of the disclosed schemes and methods above, which may be based on hardware, software, or both.
- the components of the network unit 1000 may be arranged as shown in Fig. 7.
- the content aware unit 1020 may also comprise a programmable content forwarding plane block 1028 and one or more storage blocks 1022 that may be coupled to the programmable content forwarding plane block 1028.
- the programmable content forwarding plane block 1028 may be configured to implement content forwarding and processing functions, such as at an application layer or L3 , where the content may be forwarded based on content name or prefix and possibly other content related information that maps the content to network traffic.
- Such mapping information may be maintained in one or more content tables (e.g., CS, PIT, and FIB) at the content aware unit 1020 or the network unit 1000.
- the programmable content forwarding plane block 1028 may interpret user requests for content and accordingly fetch content, e.g., based on meta-data and/or content name (prefix) , from the network or other content routers and may store the content, e.g., temporarily, in the storage blocks 1022. The programmable content forwarding plane block 1028 may then forward the cached content to the user.
- the programmable content forwarding plane block 1028 may be implemented using software, hardware, or both and may operate above the IP layer or L2.
- the storage blocks 1022 may comprise a cache 1024 for temporarily storing content, such as content that is requested by a subscriber. Additionally, the storage blocks 1022 may comprise a long-term storage 1026 for storing content relatively longer, such as content submitted by a publisher. For instance, the cache 1024 and the long-term storage 1026 may include Dynamic random-access memories (DRAMs), solid- state drives (SSDs) , hard disks, or combinations thereof.
- DRAMs Dynamic random-access memories
- SSDs solid- state drives
- the network components described above may be implemented on any general-purpose network component, such as a computer or network component with sufficient processing power, memory resources, and network throughput capability to handle the necessary workload placed upon it.
- Fig. 8 illustrates a typical, general-purpose network component 1100 suitable for implementing one or more embodiments of the components disclosed herein.
- the network component 1100 includes a processor 1102 (which may be referred to as a central processor unit or CPU) that is in communication with memory devices including secondary storage 1104, read only memory (ROM) 1106, random access memory (RAM) 1108, input/output (I/O) devices 1110, and network connectivity devices 1112.
- the processor 1102 may be implemented as one or more CPU chips, or may be part of one or more application specific integrated circuits (ASICs) .
- ASICs application specific integrated circuits
- the secondary storage 1104 is typically comprised of one or more disk drives or tape drives and is used for nonvolatile storage of data and as an over-flow data storage device if RAM 1108 is not large enough to hold all working data. Secondary storage 1104 may be used to store programs that are loaded into RAM 1108 when such programs are selected for execution.
- the ROM 1106 is used to store instructions and perhaps data that are read during program execution. ROM 1106 is a non-volatile memory device that typically has a small memory capacity relative to the larger memory capacity of secondary storage 1104.
- the RAM 1108 is used to store volatile data and perhaps to store instructions. Access to both ROM 1106 and RAM 1108 is typically faster than to secondary storage 1104.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
Abstract
Various disclosed embodiments include methods, devices and systems establishing secure discovery and secure communication in an ad hoc information-centric network (ICN). An application (18) in a consumer device (10) sends a discovery interest including an associated service name or prefix encrypted by an encryption key using the ICN (28). A producer device (20) publishing and discovery protocol (SPDP) (24) on an ICN stack (26) of the producer device receives the discovery interest and verifies the consumer device using the encryption key. The producer device SPDP returns a data protocol data unit (PDU) to the consumer device configured to enable the consumer device to access the published service, and the consumer device establishes routing with the producer device and receives the local published service.
Description
SECURE AD HOC GROUP IN AN INFORMATION-CENTRIC NETWORK
TECHNICAL FIELD
[0001] The present disclosure relates generally to an Information-centric Network (ICN) , and more specifically to Ad hoc group device-to-device communication in ICN.
BACKGROUND
[0002] The ICN is currently well suited to enable customers and service producers to discover and exchange information, such as information in an ad hoc device-to-device (D2D) scenario. However, there is currently no solution to enable both a secure discovery of information, and a secure information exchange between devices on-demand. Zero-config like protocols do not consider ad hoc group security at all. Many discovery protocols are in the application (app) level, e.g., web services discovery, and not in an ad hoc network environment .
[0003] There is desired a system and methodology enabling both a secure discovery of information in ICN, and a secure information exchange between devices on-demand.
SUMMARY
[0004] The present disclosure provides a method, device and system configured to establish secure discovery and secure communication in an ad hoc information-centric network (ICN) . In one embodiment of the disclosure, a method comprises an application in a consumer device sending a discovery interest including an associated service name or prefix encrypted by an encryption key using the ICN. A producer device publishing and discovery protocol (SPDP) on an ICN stack of the producer device receives the discovery interest from the ICN and checks to see if there is a local published service that matches the service name or prefix in the discovery interest, and if so, verifies the consumer device using the encryption key. The producer device SPDP returns a data protocol data unit (PDU) to the consumer device configured to enable the consumer device to access the published service, and the consumer device establishes routing with the producer device and receives the local published service.
[0005] In another embodiment, a producer device is configured to enable the methodology.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] For a more complete understanding of the present disclosure, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, wherein like numbers designate like objects, and in which:
[0007] FIGURE 1 illustrates a block diagram of an ICN stack on a device;
[0008] FIGURE 2 illustrates 3 steps/phases to enable secure information exchange;
[0009] FIGURE 3 illustrates a block diagram of Phase-0 service publishing;
[0010] FIGURE 4A and 4B illustrate a block diagram of secure service discovery;
[0011] FIGURE 5 illustrates a block diagram of secure binding of a consumer and producer;
[0012] FIGURE 6 illustrates a block diagram of a secure group communication;
[0013] FIGURE 7 illustrates an embodiment of a network unit; and
[0014] FIGURE 8 illustrates a typical, general-purpose network component .
DETAILED DESCRIPTION
[0015] The present disclosure provides a system and methodology enabling both a secure discovery of information in an ICN, and a secure information exchange between devices on-demand in an ad hoc ICN scenario.
[0016] Referring to Fig. 1, the present disclosure assumes a service publishing and a discovery utility, such as a service publishing discovery protocol (SPDP) for service discovery, is available on a device. Services are named and associated with policy requirements, e.g., which user or group can access a service. Routing is a result of service discovery. Each service that is discoverable to others has an identity credential. Without loss of generality, it is assumed that the identity credential is a public key (pbk) and private key (prk) pair (pbk/prk) , and the pbk is certified by some trust management mechanism such as an enterprise PKI . There is a common certificate authority (CA) for devices or services, e.g., an enterprise CA, and the CA's public key certificate is pre-installed on each device.
[0017] The present disclosure provides three steps/phases to enable the secure information exchange, as shown in Fig. 2. Phase 1 is the secure service discovery whereby services can be discovered only by authorized consumers. Phase 2 secures binding between customers and producers, whereby service discovery causes a path to be set and binds the service to valid consumers. Phase 3 secures information exchange, and ensures the data itself is secured in terms or provenance, and integrity. Considering ad hoc, keys used for information exchange should be temporal in nature.
[0018] Referring to Fig. 3, the service publishing protocol is similar as before, with the addition of new fields in the service profile:
[0019] The field <allowed_consumer> specifies a set of consumers or a group that is authorized to discovery and consume the service.
[0020] Multiple types of consumer IDs can be supported, e.g.:
[0021] xxx = Hash(pbk_c), where pbk_c is the public key certificate associated with individual service/user/device;
[0022] yyy = Hash (pbk_ca) , where pubk_ca is the public key of a
CA, e.g., a company's enterprise CA;
[0023] zzz = certified group id, user id, etc.
[0024] During the phase 1 secure service discovery, it is assumed that the service on a set of devices is affiliated to the same organization. In a general case, the device itself may not be trusted. The service can be a general network service or application, where users have pre-trust, e.g., a social application where the users are in each other's contact list.
[0025] With pre-known information (configured as part of the service) , the services installed over the devices have a mechanism to validate credentials of each other, which can be dependent or independent of the device itself. For instance, a service discovery mechanism is disclosed in commonly assigned U.S. Patent Application No. , entitled "A
Method for Name-Based Neighbor Discovery and Multi-Hop Service Discovery in Content-Oriented Network Architecture", the teachings of which are included herein in their entirety by reference. The credential, such as a public key certificate, can be verified via a trust management mechanism, e.g., a PKI . Each service has the common CA's public key certificate (pbk_ca) , such that it can verify the signature (sig) signed from another service in an off-line manner. This can be setup during installation time of the service, or by IT admin of the device .
[0026] Phase 1, Secure Service Discovery:
[0027] Referring to Fig. 4A and 4B, there is shown a preferred embodiment for secure service discovery.
[0028] 1.1. An application (app) on a consumer device sends an interest <service_discovery, pbk_c, timestamp or token, sig>, where :
pbk_c is the public key of the consumer app;
The interest protocol data unit (PDU) on the consumer device is signed by prk_c;
A timestamp or session token can be used to prevent replay attack in the discovery protocol
(http: //en.wikipedia. org/wiki/Replay_attack) ; and
A name-prefix can be included optionally and for filtering purposes, such as disclosed in the previously identified commonly assigned patent application.
[0029] 1.2. The interest is received and forwarded to a local service SPDP by the ICN in a remote node.
[0030] 1.3. The discovery protocol reaches the SPDP on service producer ICN stack, such as disclosed in the previously identified commonly assigned patent application.
[0031] 1.4. The SPDP in the service producer checks if there is local published service that matches the name or prefix in the discovery interest.
[0032] 1.5. If so, the SPDP verifies the sig with pbk_c, and verifies pbk_c with pbk_ca, where pbk_ca is the public key of the CA.
[0033] 1.6. If both verifications pass, the SPDP returns a data PDU <random_name, Enc (service_profile, pbk_c))>, where: random_name is a pseduo-random name generated by the producer, time-to-live (TTL) can also be associated wi,th this entity; service_profile is the matched local published service, which includes the real service name;
The service_profile is encrypted by the pbk_c . There are different ways of encrypting a data with a public key, e.g., http: //en.wikipedia. org/wiki/Key_encapsulation
If the verification fails, then no service-response is generated, or a service-discovery could include a n-ack that gives the consumer an indication of the failure.
[0034] 1.7. Follow the original discovery protocol, this service-response data PDU is returned to the consumer. The routing path is also set between the consumer and the service producer, such as described in the previously identified commonly assigned patent application, with the random_name as the name/prefix in FIB entries.
[0035] 1.8. The producer SPDP maintains a list of
(service_name < > random_name) mapping in its local database. Each service on local device can read the random_name of its published service_name .
[0036] 1.9. When a new discovery interest is received by the SPDP for the same service name, the SPDP first checks if there is a random_name for the service_profile available, if so it uses the random_name in the return data PDU, instead of generating a new random_name for the same service_profile .
[0037] Phase 2, Secure binding of consumer and producer:
[0038] Referring to Fig. 5, after the secure discovery phase, the ICN stack and all intermediate nodes have setup forwarding information base (FIB) entries to reach the producer from the consumer, with the random_name as entries, such as described in the previously identified commonly assigned patent application.
[0039] Advantageously, this prevents unauthorized consumers from retrieving the random_name and send an interest later.
[0040] 2.1. After receiving data PDU <random_name, Enc (service_profile, pbk_c) ) >, the consumer app decrypts with prk_c, gets the service_profile and service_name, and maintains a map of (service_name < > random_name) .
[0041] Phase 3, Secure D2D Communication:
[0042] After the discovery and binding phases, both the producer and the consumer have a valid mapping of
(service_name < > random_name) . All intermediate nodes have random_name in their FIBs . The ICN network knows nothing about service_name since the service_profile is encrypted in the discovery phase.
[0043] 3.1. The app in the consumer side sends interest <random_name, pbk_c, sig> to communicate with the producer service, where the sig is a signature generated with prk_c .
[0044] 3.2. The interest is routed to the service app in producer, following the ICN protocols.
[0045] 3.3. The service app checks local (service_name < > random_name) mapping, and obtains the corresponding service_name .
[0046] 3.4. The service app then generates the data payload, as usual application functions, and returns the data PDU <random_name, Enc (payload, pbk_c))>. Optionally, before it returns the data PDU, the service app checks its local security policy if pbk_c is allowed to receive its data. Again, there can be many ways for using pbk_c to encrypt the data payload, e.g., http: //en.wikipedia. org/wiki/Key_encapsulation.
[0047] 3.5. The PDU returns to the consumer app, following basic ICN protocols.
[0048] 3.6. The app decrypts the data payload with prk_c, and obtains the corresponding service_name with random_name in its local mapping.
[0049] 3.7. The app consumes data <service_name, payload>.
[0050] Phase 3: Secure Group Communication:
[0051] Referring now to Fig. 6:
[0052] 1.1 For a group communication case:
[0053] 1.2 Each consumer follows the same secure discovery protocol to discover the service_profile .
[0054] 1.3 During the secure discovery protocol, the service producer SPDP first generates a symmetric group_session_key,
and returns the data PDU <random_name, Enc (service_profile, group_session _key, pbk_c))>, where:
[0055] random_name is a pseudo-random name generated by the producer;
[0056] service_profile is the matched local published service, which includes the real service name;
[0057] Group_session_key is a symmetric key (e.g., AES) for the group; and options may be available for using pbk_c to encrypt the service_profile and group_session_key.
[0058] 1.4 In Step 2.1, after receiving the data PDU <random_name, Enc (service_profile, group_session_key, pbk_c) ) >, the consumer app decrypts the data PDU with prk_c, and gets the service_profile and service_name . It then maintains a map of (service_name < > random_name < > group_session_key) .
[0059] 1.5 As in the previous case, the random_name is used to bind the service and its consumers. When another group member (say consumer 2 with pbk_c2) discovers the same service name, the producer SPDP checks if there is local (service_name < > random_name < > group_session_key) . If so, it returns the data PDU <random_name, Enc (service_profile, group_session_key, pbk_c2)). The consumer 2 app decrypts the data PDU with prk_c2 and obtains the service profile and the service name, similar to the first consumer. This way, multiple interactive applications agree on the same random- name and group key. The same group key encrypted content can be cached in the network, and can use multicasting.
[0060] 1.6. The app in consumer side sends the interest <random_name> to communicate with the producer service.
[0061] 1.7. The interest is routed to the service app in producer, following ICN protocols.
[0062] 1.8. The service app checks local <service_name, random_name> , and obtains the corresponding service_name .
[0063] 1.9. The service app then generates the data payload, as usual application functions, and returns the data PDU <random_name, Enc (payload, group_session_key) >
[0064] Optionally, before returning the data PDU, the service checks its local security policy if pbk_c is allowed to receive its data.
[0065] Again, there can be many ways for using pbk_c to encrypt the data payload, e.g., http : / /en.wikipedia. org/wiki/Key_encapsulation
[0066] 1.10. The PDU returns to the consumer app, following basic ICN protocols.
[0067] 1.11. The app decrypts the data payload with group_session_key, and obtains the corresponding service_name with the random_name in its local mapping.
[0068] 1.12. The app consumes data <random_name, payload>.
[0069] Fig. 7 illustrates an embodiment of a network unit 1000, which may be any device that transports and processes data through network 100. For instance, the network unit 1000 may correspond to or may be located in any of the system nodes described above, such as a M , PoA, content router R, and AS. The network unit 1000 may also be configured to implement or support the schemes and methods described above. The network unit 1000 may comprise one or more ingress ports or units 1010 coupled to a receiver (Rx) 1012 for receiving signals and frames/data from other network components. The network unit 1000 may comprise a content aware unit 1020 to determine which network components to send content to. The content aware unit 1020 may be implemented using hardware, software, or both. The network unit 1000 may also comprise one or more egress ports or units 1030 coupled to a transmitter (Tx) 1032 for transmitting signals and frames/data to the other network components. The receiver 1012, content aware unit 1020, and transmitter 1032 may also be configured to implement at least some of the disclosed schemes and methods above, which may be
based on hardware, software, or both. The components of the network unit 1000 may be arranged as shown in Fig. 7.
[0070] The content aware unit 1020 may also comprise a programmable content forwarding plane block 1028 and one or more storage blocks 1022 that may be coupled to the programmable content forwarding plane block 1028. The programmable content forwarding plane block 1028 may be configured to implement content forwarding and processing functions, such as at an application layer or L3 , where the content may be forwarded based on content name or prefix and possibly other content related information that maps the content to network traffic. Such mapping information may be maintained in one or more content tables (e.g., CS, PIT, and FIB) at the content aware unit 1020 or the network unit 1000. The programmable content forwarding plane block 1028 may interpret user requests for content and accordingly fetch content, e.g., based on meta-data and/or content name (prefix) , from the network or other content routers and may store the content, e.g., temporarily, in the storage blocks 1022. The programmable content forwarding plane block 1028 may then forward the cached content to the user. The programmable content forwarding plane block 1028 may be implemented using software, hardware, or both and may operate above the IP layer or L2.
[0071] The storage blocks 1022 may comprise a cache 1024 for temporarily storing content, such as content that is requested by a subscriber. Additionally, the storage blocks 1022 may comprise a long-term storage 1026 for storing content relatively longer, such as content submitted by a publisher. For instance, the cache 1024 and the long-term storage 1026 may include Dynamic random-access memories (DRAMs), solid- state drives (SSDs) , hard disks, or combinations thereof.
[0072] The network components described above may be implemented on any general-purpose network component, such as
a computer or network component with sufficient processing power, memory resources, and network throughput capability to handle the necessary workload placed upon it. Fig. 8 illustrates a typical, general-purpose network component 1100 suitable for implementing one or more embodiments of the components disclosed herein. The network component 1100 includes a processor 1102 (which may be referred to as a central processor unit or CPU) that is in communication with memory devices including secondary storage 1104, read only memory (ROM) 1106, random access memory (RAM) 1108, input/output (I/O) devices 1110, and network connectivity devices 1112. The processor 1102 may be implemented as one or more CPU chips, or may be part of one or more application specific integrated circuits (ASICs) .
[0073] The secondary storage 1104 is typically comprised of one or more disk drives or tape drives and is used for nonvolatile storage of data and as an over-flow data storage device if RAM 1108 is not large enough to hold all working data. Secondary storage 1104 may be used to store programs that are loaded into RAM 1108 when such programs are selected for execution. The ROM 1106 is used to store instructions and perhaps data that are read during program execution. ROM 1106 is a non-volatile memory device that typically has a small memory capacity relative to the larger memory capacity of secondary storage 1104. The RAM 1108 is used to store volatile data and perhaps to store instructions. Access to both ROM 1106 and RAM 1108 is typically faster than to secondary storage 1104.
[0074] It may be advantageous to set forth definitions of certain words and phrases used throughout this patent document. The terms "include" and "comprise," as well as derivatives thereof, mean inclusion without limitation. The term "or" is inclusive, meaning and/or. The phrases "associated with" and "associated therewith, " as well as
derivatives thereof, mean to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, or the like.
[0075] While this disclosure has described certain embodiments and generally associated methods, alterations and permutations of these embodiments and methods will be apparent to those skilled in the art. Accordingly, the above description of example embodiments does not define or constrain this disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of this disclosure, as defined by the following claims.
Claims
1. A method of establishing secure discovery and secure communication in an ad hoc information-centric network (ICN) , comprising:
an application in a consumer device sending a discovery interest including an associated service name or prefix signed by an encryption key using the ICN;
a producer device publishing and discovery protocol (SPDP) on an ICN stack of a producer device receiving the discovery interest from the ICN and checking to see if there is a local published service that matches the service name or prefix in the discovery interest, and if so, verifying the consumer device using the encryption key;
the producer device SPDP returning a data protocol data unit (PDU) to the consumer device configured to enable the consumer device to access the local published service; and the consumer device establishing routing with the producer device and receiving the local published service.
2. The method as specified in Claim 1 wherein the data PDU includes a random name, a service profile, and a public key.
3. The method as specified in Claim 2 wherein the random name is a pseudo-random name generated by the producer
device, and the service profile is the matched local published service including a real service name.
4. The method as specified in Claim 3 wherein the producer device SPDP has a local database that maintains a list of service names mapped to pseudo-random names.
5. The method as specified in Claim 4 wherein when the producer device SPDP receives a new discovery interest for the same service name, it first checks if there is a mapped random name for the service profile, and if so, includes the random name in a returned data PDU instead of generating a new random name for the same service profile, and responds by encrypting the discovery response.
6. The method as specified in Claim 2 wherein the producer device ICN stack, an ICN stack of the consumer device, and intermediate nodes of the ICN have forwarding information base (FIB ) entries configured to enable the consumer device to reach the producer device using the random names as entries.
7. The method as specified in Claim 1 wherein upon receiving the data PDU, the consumer device application decrypts the data PDU to obtain the service profile and a service name.
8. The method as specified in Claim 4 wherein the consumer device maintains a map of the service name and random name .
9. The method as specified in Claim 2 wherein the consumer device application sends a service interest signed by the encryption key and including its associated random name to the producer device by ICN protocols .
10. The method as specified in Claim 9 wherein the producer device checks the associated random name using local mapping, and obtains the corresponding service name.
11. The method as specified in Claim 10 wherein the producer device checks its local security policy to see if the encryption key is authorized to be used to return the data PDU to the consumer device.
12. The method as specified in Claim 10 wherein the producer device generates a data payload, and returns a data PDU including the data payload encrypted using the encryption key to the consumer device using ICN protocols .
13. The method as specified in Claim 1 wherein the data PDU includes a random name, a service profile, and a group session key.
14. The method as specified in Claim 13 wherein multiple said consumer devices send a discovery interest including an associated service name or prefix encrypted by an encryption key using the ICN, and receive and decrypt the data PDU with the group session key to obtain the same random name and service profile.
15. A producer device for establishing secure discovery and secure communication in an ad hoc information-centric network (ICN) , comprising:
the producer device configured to receive a discovery interest from an application in a consumer device including an associated service name or prefix signed by an encryption key using the ICN;
the producer device including a producer device publishing and discovery protocol (SPDP) on an ICN stack configured to receive the discovery interest from the ICN and check to see if there is a local published service that matches the service name or prefix in the discovery interest, and if so, verify the consumer device using the encryption key;
the producer device SPDP configured to return a data protocol data unit (PDU) to the consumer device configured to enable the consumer device to access the local published service; and
the consumer device configured to establish routing with the producer device and receive the local published service .
16. The producer device as specified in Claim 15 wherein the data PDU includes a random name, a service profile, and a public key.
17. The producer device as specified in Claim 16 wherein the random name is a pseudo-random name generated by the producer device, and the service profile is the matched local published service including a real service name.
18. The producer device as specified in Claim 17 wherein the producer device SPDP has a local database that is configured to maintain a list of service names mapped to pseudo-random names.
19. The producer device as specified in Claim 18 configured such that when the producer device SPDP receives a new discovery interest for the same service name, it first checks if there is a mapped random name for the service profile, and if so, includes the random name in a returned data PDU instead of generating a new random name for the same service profile, and responds by encrypting the discovery response .
20. The producer device as specified in Claim 16 wherein the producer device ICN stack has a forwarding information base (FIB) entry configured to enable the consumer device to reach the producer device using the random names as entries.
21. The producer device as specified in Claim 15 wherein the producer device is configured to enable the consumer
device application upon receiving the data PDU to decrypt the data PDU to obtain the service profile and a service name.
22. The producer device as specified in Claim 18 wherein the producer device is configured to enable the consumer device to maintain a map of the service name and random name.
23. The producer device as specified in Claim 16 wherein the producer device is configured to receive a service interest from the consumer device application signed by the encryption key and including its associated random name to the producer device by ICN protocols .
24. The producer device as specified in Claim 23 wherein the producer device is configured to check the associated random name using local mapping, and obtain the corresponding service name.
25. The producer device as specified in Claim 24 wherein the producer device is configured to check its local security policy to see if the encryption key is authorized to be used to return the data PDU to the consumer device .
26. The producer device as specified in Claim 24 wherein the producer device is configured to generate a data payload, and return a data PDU including the data payload encrypted
using the encryption key to the consumer device using ICN protocols .
27. The producer device as specified in Claim 15 wherein the data PDU includes a random name, a service profile, and a group session key.
28. The producer device as specified in Claim 27 wherein the producer device is configured to receive discovery interests from multiple consumer devices including an associated service name or prefix encrypted by the group session key.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP15740694.3A EP3092837B1 (en) | 2014-01-22 | 2015-01-20 | Secure ad hoc group in an information-centric network |
CN201580004885.5A CN105917689B (en) | 2014-01-22 | 2015-01-20 | Secure peer-to-peer groups in information-centric networks |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/161,458 US9313030B2 (en) | 2014-01-22 | 2014-01-22 | Method and apparatus for secure ad hoc group device-to-device communication in information-centric network |
US14/161,458 | 2014-01-22 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2015112499A1 true WO2015112499A1 (en) | 2015-07-30 |
Family
ID=53545770
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2015/012049 WO2015112499A1 (en) | 2014-01-22 | 2015-01-20 | Secure ad hoc group in an information-centric network |
Country Status (4)
Country | Link |
---|---|
US (1) | US9313030B2 (en) |
EP (1) | EP3092837B1 (en) |
CN (1) | CN105917689B (en) |
WO (1) | WO2015112499A1 (en) |
Families Citing this family (84)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9456054B2 (en) | 2008-05-16 | 2016-09-27 | Palo Alto Research Center Incorporated | Controlling the spread of interests and content in a content centric network |
US8923293B2 (en) | 2009-10-21 | 2014-12-30 | Palo Alto Research Center Incorporated | Adaptive multi-interface use for content networking |
US10098051B2 (en) | 2014-01-22 | 2018-10-09 | Cisco Technology, Inc. | Gateways and routing in software-defined manets |
US9954678B2 (en) | 2014-02-06 | 2018-04-24 | Cisco Technology, Inc. | Content-based transport security |
US9836540B2 (en) | 2014-03-04 | 2017-12-05 | Cisco Technology, Inc. | System and method for direct storage access in a content-centric network |
US9626413B2 (en) | 2014-03-10 | 2017-04-18 | Cisco Systems, Inc. | System and method for ranking content popularity in a content-centric network |
US9716622B2 (en) | 2014-04-01 | 2017-07-25 | Cisco Technology, Inc. | System and method for dynamic name configuration in content-centric networks |
US9473576B2 (en) | 2014-04-07 | 2016-10-18 | Palo Alto Research Center Incorporated | Service discovery using collection synchronization with exact names |
US9451032B2 (en) * | 2014-04-10 | 2016-09-20 | Palo Alto Research Center Incorporated | System and method for simple service discovery in content-centric networks |
US9992281B2 (en) | 2014-05-01 | 2018-06-05 | Cisco Technology, Inc. | Accountable content stores for information centric networks |
US9609014B2 (en) | 2014-05-22 | 2017-03-28 | Cisco Systems, Inc. | Method and apparatus for preventing insertion of malicious content at a named data network router |
US9699198B2 (en) | 2014-07-07 | 2017-07-04 | Cisco Technology, Inc. | System and method for parallel secure content bootstrapping in content-centric networks |
US9621354B2 (en) | 2014-07-17 | 2017-04-11 | Cisco Systems, Inc. | Reconstructable content objects |
US9729616B2 (en) | 2014-07-18 | 2017-08-08 | Cisco Technology, Inc. | Reputation-based strategy for forwarding and responding to interests over a content centric network |
US9590887B2 (en) | 2014-07-18 | 2017-03-07 | Cisco Systems, Inc. | Method and system for keeping interest alive in a content centric network |
US9882964B2 (en) | 2014-08-08 | 2018-01-30 | Cisco Technology, Inc. | Explicit strategy feedback in name-based forwarding |
US9729662B2 (en) | 2014-08-11 | 2017-08-08 | Cisco Technology, Inc. | Probabilistic lazy-forwarding technique without validation in a content centric network |
US9800637B2 (en) | 2014-08-19 | 2017-10-24 | Cisco Technology, Inc. | System and method for all-in-one content stream in content-centric networks |
US10069933B2 (en) | 2014-10-23 | 2018-09-04 | Cisco Technology, Inc. | System and method for creating virtual interfaces based on network characteristics |
US9590948B2 (en) | 2014-12-15 | 2017-03-07 | Cisco Systems, Inc. | CCN routing using hardware-assisted hash tables |
US10237189B2 (en) | 2014-12-16 | 2019-03-19 | Cisco Technology, Inc. | System and method for distance-based interest forwarding |
US10003520B2 (en) | 2014-12-22 | 2018-06-19 | Cisco Technology, Inc. | System and method for efficient name-based content routing using link-state information in information-centric networks |
US9660825B2 (en) | 2014-12-24 | 2017-05-23 | Cisco Technology, Inc. | System and method for multi-source multicasting in content-centric networks |
US9946743B2 (en) | 2015-01-12 | 2018-04-17 | Cisco Technology, Inc. | Order encoded manifests in a content centric network |
US9916457B2 (en) | 2015-01-12 | 2018-03-13 | Cisco Technology, Inc. | Decoupled name security binding for CCN objects |
US9832291B2 (en) | 2015-01-12 | 2017-11-28 | Cisco Technology, Inc. | Auto-configurable transport stack |
US9954795B2 (en) | 2015-01-12 | 2018-04-24 | Cisco Technology, Inc. | Resource allocation using CCN manifests |
US10333840B2 (en) | 2015-02-06 | 2019-06-25 | Cisco Technology, Inc. | System and method for on-demand content exchange with adaptive naming in information-centric networks |
US10075401B2 (en) | 2015-03-18 | 2018-09-11 | Cisco Technology, Inc. | Pending interest table behavior |
US9729541B2 (en) * | 2015-03-31 | 2017-08-08 | Here Global B.V. | Method and apparatus for migrating encrypted data |
US10075402B2 (en) | 2015-06-24 | 2018-09-11 | Cisco Technology, Inc. | Flexible command and control in content centric networks |
US10701038B2 (en) | 2015-07-27 | 2020-06-30 | Cisco Technology, Inc. | Content negotiation in a content centric network |
US9986034B2 (en) | 2015-08-03 | 2018-05-29 | Cisco Technology, Inc. | Transferring state in content centric network stacks |
US9832123B2 (en) | 2015-09-11 | 2017-11-28 | Cisco Technology, Inc. | Network named fragments in a content centric network |
US10355999B2 (en) | 2015-09-23 | 2019-07-16 | Cisco Technology, Inc. | Flow control with network named fragments |
US9977809B2 (en) | 2015-09-24 | 2018-05-22 | Cisco Technology, Inc. | Information and data framework in a content centric network |
US10313227B2 (en) | 2015-09-24 | 2019-06-04 | Cisco Technology, Inc. | System and method for eliminating undetected interest looping in information-centric networks |
US10454820B2 (en) | 2015-09-29 | 2019-10-22 | Cisco Technology, Inc. | System and method for stateless information-centric networking |
US10263965B2 (en) | 2015-10-16 | 2019-04-16 | Cisco Technology, Inc. | Encrypted CCNx |
US9794238B2 (en) * | 2015-10-29 | 2017-10-17 | Cisco Technology, Inc. | System for key exchange in a content centric network |
US9807205B2 (en) | 2015-11-02 | 2017-10-31 | Cisco Technology, Inc. | Header compression for CCN messages using dictionary |
US10097521B2 (en) * | 2015-11-20 | 2018-10-09 | Cisco Technology, Inc. | Transparent encryption in a content centric network |
US9912776B2 (en) | 2015-12-02 | 2018-03-06 | Cisco Technology, Inc. | Explicit content deletion commands in a content centric network |
US10097346B2 (en) | 2015-12-09 | 2018-10-09 | Cisco Technology, Inc. | Key catalogs in a content centric network |
US10078062B2 (en) | 2015-12-15 | 2018-09-18 | Palo Alto Research Center Incorporated | Device health estimation by combining contextual information with sensor data |
US10257271B2 (en) | 2016-01-11 | 2019-04-09 | Cisco Technology, Inc. | Chandra-Toueg consensus in a content centric network |
US9949301B2 (en) | 2016-01-20 | 2018-04-17 | Palo Alto Research Center Incorporated | Methods for fast, secure and privacy-friendly internet connection discovery in wireless networks |
US10305864B2 (en) | 2016-01-25 | 2019-05-28 | Cisco Technology, Inc. | Method and system for interest encryption in a content centric network |
US10043016B2 (en) | 2016-02-29 | 2018-08-07 | Cisco Technology, Inc. | Method and system for name encryption agreement in a content centric network |
US10003507B2 (en) | 2016-03-04 | 2018-06-19 | Cisco Technology, Inc. | Transport session state protocol |
US10742596B2 (en) | 2016-03-04 | 2020-08-11 | Cisco Technology, Inc. | Method and system for reducing a collision probability of hash-based names using a publisher identifier |
US10051071B2 (en) | 2016-03-04 | 2018-08-14 | Cisco Technology, Inc. | Method and system for collecting historical network information in a content centric network |
US10038633B2 (en) | 2016-03-04 | 2018-07-31 | Cisco Technology, Inc. | Protocol to query for historical network information in a content centric network |
US9832116B2 (en) | 2016-03-14 | 2017-11-28 | Cisco Technology, Inc. | Adjusting entries in a forwarding information base in a content centric network |
US10212196B2 (en) | 2016-03-16 | 2019-02-19 | Cisco Technology, Inc. | Interface discovery and authentication in a name-based network |
US10067948B2 (en) | 2016-03-18 | 2018-09-04 | Cisco Technology, Inc. | Data deduping in content centric networking manifests |
US11436656B2 (en) | 2016-03-18 | 2022-09-06 | Palo Alto Research Center Incorporated | System and method for a real-time egocentric collaborative filter on large datasets |
US10091330B2 (en) | 2016-03-23 | 2018-10-02 | Cisco Technology, Inc. | Interest scheduling by an information and data framework in a content centric network |
US10033639B2 (en) | 2016-03-25 | 2018-07-24 | Cisco Technology, Inc. | System and method for routing packets in a content centric network using anonymous datagrams |
US10320760B2 (en) | 2016-04-01 | 2019-06-11 | Cisco Technology, Inc. | Method and system for mutating and caching content in a content centric network |
US9930146B2 (en) | 2016-04-04 | 2018-03-27 | Cisco Technology, Inc. | System and method for compressing content centric networking messages |
US10425503B2 (en) | 2016-04-07 | 2019-09-24 | Cisco Technology, Inc. | Shared pending interest table in a content centric network |
US10027578B2 (en) | 2016-04-11 | 2018-07-17 | Cisco Technology, Inc. | Method and system for routable prefix queries in a content centric network |
US10404450B2 (en) | 2016-05-02 | 2019-09-03 | Cisco Technology, Inc. | Schematized access control in a content centric network |
US10320675B2 (en) | 2016-05-04 | 2019-06-11 | Cisco Technology, Inc. | System and method for routing packets in a stateless content centric network |
US10547589B2 (en) | 2016-05-09 | 2020-01-28 | Cisco Technology, Inc. | System for implementing a small computer systems interface protocol over a content centric network |
US10063414B2 (en) | 2016-05-13 | 2018-08-28 | Cisco Technology, Inc. | Updating a transport stack in a content centric network |
US10084764B2 (en) | 2016-05-13 | 2018-09-25 | Cisco Technology, Inc. | System for a secure encryption proxy in a content centric network |
US10103989B2 (en) | 2016-06-13 | 2018-10-16 | Cisco Technology, Inc. | Content object return messages in a content centric network |
US10305865B2 (en) | 2016-06-21 | 2019-05-28 | Cisco Technology, Inc. | Permutation-based content encryption with manifests in a content centric network |
US10148572B2 (en) | 2016-06-27 | 2018-12-04 | Cisco Technology, Inc. | Method and system for interest groups in a content centric network |
US10009266B2 (en) | 2016-07-05 | 2018-06-26 | Cisco Technology, Inc. | Method and system for reference counted pending interest tables in a content centric network |
US9992097B2 (en) | 2016-07-11 | 2018-06-05 | Cisco Technology, Inc. | System and method for piggybacking routing information in interests in a content centric network |
US10122624B2 (en) | 2016-07-25 | 2018-11-06 | Cisco Technology, Inc. | System and method for ephemeral entries in a forwarding information base in a content centric network |
US10069729B2 (en) | 2016-08-08 | 2018-09-04 | Cisco Technology, Inc. | System and method for throttling traffic based on a forwarding information base in a content centric network |
US10956412B2 (en) | 2016-08-09 | 2021-03-23 | Cisco Technology, Inc. | Method and system for conjunctive normal form attribute matching in a content centric network |
US10033642B2 (en) | 2016-09-19 | 2018-07-24 | Cisco Technology, Inc. | System and method for making optimal routing decisions based on device-specific parameters in a content centric network |
US10212248B2 (en) | 2016-10-03 | 2019-02-19 | Cisco Technology, Inc. | Cache management on high availability routers in a content centric network |
US10447805B2 (en) | 2016-10-10 | 2019-10-15 | Cisco Technology, Inc. | Distributed consensus in a content centric network |
US10135948B2 (en) | 2016-10-31 | 2018-11-20 | Cisco Technology, Inc. | System and method for process migration in a content centric network |
US10243851B2 (en) | 2016-11-21 | 2019-03-26 | Cisco Technology, Inc. | System and method for forwarder connection information in a content centric network |
US10736155B2 (en) | 2017-12-15 | 2020-08-04 | Huawei Technologies Co., Ltd. | Shared PDU session establishment and binding |
US10673695B2 (en) | 2018-03-06 | 2020-06-02 | Kaloom Inc. | Computing device and method for performing a fabric deployment in a data center |
US11005667B2 (en) | 2018-03-19 | 2021-05-11 | Kaloom Inc. | Computing device and method for performing a secure neighbor discovery |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070195760A1 (en) * | 2006-02-23 | 2007-08-23 | Mahfuzur Rahman | Light weight service discovery protocol |
US20090016524A1 (en) * | 2007-07-10 | 2009-01-15 | Qualcomm Incorporated | Peer to peer identifiers |
WO2013118096A1 (en) * | 2012-02-10 | 2013-08-15 | Renesas Mobile Corporation | Method, apparatus and computer program for facilitating secure d2d discovery information |
US20130282860A1 (en) * | 2012-04-20 | 2013-10-24 | Futurewei Technologies, Inc. | Name-Based Neighbor Discovery and Multi-Hop Service Discovery in Information-Centric Networks |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7685288B2 (en) * | 2003-06-30 | 2010-03-23 | Microsoft Corporation | Ad-hoc service discovery protocol |
US8386622B2 (en) * | 2008-05-16 | 2013-02-26 | Palo Alto Research Center Incorporated | Method and apparatus for facilitating communication in a content centric network |
EP2634991B1 (en) * | 2012-02-28 | 2017-08-02 | Alcatel Lucent | Content-centric networking |
EP2915354A4 (en) * | 2012-11-01 | 2016-06-29 | Lg Electronics Inc | Method and apparatus of providing integrity protection for proximity-based service discovery with extended discovery range |
-
2014
- 2014-01-22 US US14/161,458 patent/US9313030B2/en active Active
-
2015
- 2015-01-20 EP EP15740694.3A patent/EP3092837B1/en active Active
- 2015-01-20 CN CN201580004885.5A patent/CN105917689B/en active Active
- 2015-01-20 WO PCT/US2015/012049 patent/WO2015112499A1/en active Application Filing
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070195760A1 (en) * | 2006-02-23 | 2007-08-23 | Mahfuzur Rahman | Light weight service discovery protocol |
US20090016524A1 (en) * | 2007-07-10 | 2009-01-15 | Qualcomm Incorporated | Peer to peer identifiers |
WO2013118096A1 (en) * | 2012-02-10 | 2013-08-15 | Renesas Mobile Corporation | Method, apparatus and computer program for facilitating secure d2d discovery information |
US20130282860A1 (en) * | 2012-04-20 | 2013-10-24 | Futurewei Technologies, Inc. | Name-Based Neighbor Discovery and Multi-Hop Service Discovery in Information-Centric Networks |
Non-Patent Citations (2)
Title |
---|
ALMENAREZ ET AL.: "SPDP: A Secure Service Discovery Protocol for Ad-hoc Networks'';", vol. 26, 2003, pages 1 - 8, XP055214767, Retrieved from the Internet <URL:http://www.it.uc3m.es/-celeste/papers/eunice2003_spdp.pdf> [retrieved on 20140416] * |
BISWAS ET AL.: "Contextualized Information-Centric Home Network", vol. 26, August 2013 (2013-08-01), pages 1 - 2, XP055214769, Retrieved from the Internet <URL:http://dl.acm.org/citation.cfm?id=2491691> [retrieved on 20140416] * |
Also Published As
Publication number | Publication date |
---|---|
EP3092837A1 (en) | 2016-11-16 |
CN105917689B (en) | 2020-01-31 |
CN105917689A (en) | 2016-08-31 |
EP3092837B1 (en) | 2018-12-05 |
EP3092837A4 (en) | 2016-12-21 |
US9313030B2 (en) | 2016-04-12 |
US20150207633A1 (en) | 2015-07-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9313030B2 (en) | Method and apparatus for secure ad hoc group device-to-device communication in information-centric network | |
US9009465B2 (en) | Augmenting name/prefix based routing protocols with trust anchor in information-centric networks | |
RU2571394C2 (en) | Method and apparatus for using identification information for digital signing and encrypting content integrity and authenticity in content oriented networks | |
US11303431B2 (en) | Method and system for performing SSL handshake | |
US9225721B2 (en) | Distributing overlay network ingress information | |
TWI654866B (en) | Gateway, client device and methods for facilitating communication between a client device and an application server | |
US10951421B2 (en) | Accessing hosts in a computer network | |
US10764263B2 (en) | Authentication of users in a computer network | |
Ma et al. | An architecture for accountable anonymous access in the internet-of-things network | |
US10666755B2 (en) | Method and apparatus for secure content caching and delivery | |
US10158610B2 (en) | Secure application communication system | |
EP3328025B1 (en) | Accessing hosts in a hybrid computer network | |
US7877608B2 (en) | Secure inter-process communications | |
Leshov et al. | Content name privacy in tactical named data networking | |
CN116074028A (en) | Access control method, device and system for encrypted traffic | |
Nandini | Efficient-way of Data Storage on Decentralized Cloud using Blockchain Technology | |
Krähenbühl et al. | Ubiquitous Secure Communication in a Future Internet Architecture | |
EP4323898A1 (en) | Computer-implemented methods and systems for establishing and/or controlling network connectivity | |
Khan et al. | Location identity based content security scheme for content centric networking |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 15740694 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
REEP | Request for entry into the european phase |
Ref document number: 2015740694 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2015740694 Country of ref document: EP |