System and method for protected spoke to spoke communication using an unprotected computer network

• US 7,962,743 B2
• Filed: 05/22/2006
• Issued: 06/14/2011
• Est. Priority Date: 05/22/2006
• Status: Active Grant

• Current Assignee: Cisco Technology, Inc. (Cisco Systems, Inc.)
• Original Assignee: Cisco Technology, Inc. (Cisco Systems, Inc.)
• Inventors: Fluhrer, Scott
• Primary Examiner(s): Arani; Taghi T
• Assistant Examiner(s): HERZOG, MADHURI R
• Application Number:
  US11/419,583
• Publication Number:
  US 20070271451A1
• Time in Patent Office: 1,849 Days
• Field of Search: 713150-153, 713162-163, 726/2, 726/3, 726 12- 15, 709238-244
• US Class Current: 713/153
• CPC Class Codes: H04L 63/0442 wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption cryptographic mechanisms or cryptographic arrangements for public-key encryption H04L9/30
• CPC Class Codes: H04L 9/0841 involving Diffie-Hellman or related key agreement protocols
• CPC Class Codes: H04L 9/0891 Revocation or update of secret information, e.g. encryption key update or rekeying

Abstract

Various embodiments of the disclosed subject matter provide methods and systems for improved efficiency and security in spoke-to-spoke network communication. Embodiments provide systems and methods for registering a spoke with a hub, updating a hub registration table with spoke registration information, sending the updated hub registration table to a plurality of registered spokes, using the updated hub registration table at a sending spoke to encrypt traffic to be sent to another spoke, and using the updated hub registration table at a receiving spoke to decrypt traffic received from another spoke.

Claims

1. A method comprising:

registering a spoke with a hub;

updating a hub registration table with spoke registration information;

sending the updated hub registration table to a plurality of registered spokes;

using information in the updated hub registration table at a sending spoke to resolve an address of a receiving spoke without accessing the hub, the information in the updated hub registration table at the sending spoke including information sufficient to resolve the address of the receiving spoke even if the sending spoke has not previously sent traffic to the receiving spoke since the sending spoke registered with the hub;

using information in the updated hub registration table at the sending spoke to encrypt traffic to be sent to the receiving spoke without accessing the hub; and

sending the encrypted traffic directly to the receiving spoke without sending the encrypted traffic via the hub.

2. The method as claimed in claim 1 including using information in the updated hub registration table at a receiving spoke to decrypt traffic received from the sending spoke without accessing the hub and determining if a tunnel has been established with the receiving spoke.

3. The method as claimed in claim 1 including determining if a tunnel has been established with the receiving spoke.

5. The method as claimed in claim 1 wherein registering a spoke with a hub further including providing spoke registration information including an IP address, a subnet, and a public key value for a registering spoke.

6. The method as claimed in claim 5 including, if a tunnel has not been established with the receiving spoke, obtaining the subnet and the corresponding public key value of the receiving spoke from the updated hub registration table at the sending spoke, combining the public key value of the receiving spoke with a private key value of the sending spoke to form an encryption key, using the encryption key to create a tunnel to the receiving spoke, and sending the encrypted traffic via the tunnel without transiting the hub.

7. The method as claimed in claim 1 wherein the hub maintains the updated hub registration table, the method further including receiving an updated copy of the hub registration table at the first spoke.

8. The method as claimed in claim 1 wherein traffic to be sent to another spoke is encrypted using a Diffie-Hellman key.

4. The method as claimed in 1 including obtaining a subnet and a corresponding public key value of the receiving spoke from the updated hub registration table at the sending spoke without accessing the hub, combining the public key value of the receiving spoke with a private key value of the sending spoke to form an encryption key, using the encryption key to create a tunnel to the receiving spoke, and sending the encrypted traffic via the tunnel without transiting the hub.

9. A method comprising:

registering a first spoke with a hub by providing to the hub first spoke registration information including an IP address, a subnet, and a public key value for the first spoke;

receiving an updated hub registration table from the hub, the updated hub registration table including spoke registration information for a plurality of spokes;

using information in the updated hub registration table at the first spoke to resolve an address of a second spoke without accessing the hub, the information in the updated hub registration table at the first spoke including information sufficient to resolve the address of the second spoke even if the first spoke has not previously sent traffic to the second spoke since the first spoke registered with the hub;

using information in the updated hub registration table at the first spoke to encrypt traffic to be sent to a second spoke without accessing the hub; and

sending the encrypted traffic directly from the first spoke to the second spoke without sending the encrypted traffic via the hub.

10. The method as claimed in claim 9 including determining if a tunnel has been established between the first spoke and the second spoke.

11. The method as claimed in claim 9 including obtaining the subnet and the corresponding public key value of the second spoke from the updated hub registration table at the first spoke, combining the public key value of the second spoke with a private key value of the first spoke to form an encryption key, using the encryption key to create a tunnel between the first spoke and the second spoke, and sending encrypted traffic via the tunnel without transiting the hub.

12. A method comprising:

determining if a tunnel has been established between a first spoke and a second spoke; and

if a tunnel has not been established between the first spoke and the second spoke, obtaining a subnet address and a corresponding public key value of the second spoke from a hub registration table at the first spoke without accessing the hub, combining the public key value of the second spoke with a private key value of the first spoke to form an encryption key, using the encryption key to create a tunnel between the first spoke and the second spoke, using information in the hub registration table at the first spoke to encrypt traffic to be sent to the second spoke without accessing the hub, the information in the hub registration table at the first spoke including information sufficient to encrypt traffic to be sent to the second spoke even if the first spoke has not previously sent traffic to the second spoke since the first spoke registered with the hub, and sending the encrypted traffic directly from the first spoke to the second spoke without sending the encrypted traffic via a hub.

13. The method as claimed in claim 12 wherein the hub maintains the hub registration table, the method further including receiving an updated copy of the hub registration table at the first spoke.

14. The method as claimed in claim 12 wherein encrypted traffic to be sent via the tunnel is encrypted using a Diffie-Hellman key.

15. A method comprising:

receiving encrypted traffic from a first spoke;

determining if a tunnel has been established between the first spoke and a second spoke; and

if a tunnel has not been established between the first spoke and the second spoke, obtaining an IP address of the first spoke and a corresponding public key value of the first spoke from a hub registration table at the second spoke without accessing the hub, combining the public key value of the first spoke with a private key value of the second spoke to form a decryption key, using the decryption key to create a tunnel between the first spoke and the second spoke, and using information in the hub registration table at the second spoke to decrypt traffic received from the first spoke without accessing the hub, the information in the hub registration table at the second spoke including information sufficient to decrypt traffic received from the first spoke even if the second spoke has not previously received traffic from the first spoke since the second spoke registered with the hub, the encrypted traffic being received directly from the first spoke at the second spoke without being sent via a hub.

16. The method as claimed in claim 15 wherein the hub maintains the hub registration table, the method further including receiving an updated copy of the hub registration table at the second spoke.

17. The method as claimed in claim 15 wherein the encrypted traffic is encrypted using a Diffie-Hellman key.

18. An apparatus comprising:

means for registering a spoke with a hub;

means for updating a hub registration table with spoke registration information;

means for sending the updated hub registration table to a plurality of registered spokes;

means for using information in the updated hub registration table at a sending spoke to resolve an address of a receiving spoke without accessing the hub, the information in the updated hub registration table at the sending spoke including information sufficient to resolve the address of the receiving spoke even if the sending spoke has not previously sent traffic to the receiving spoke since the sending spoke registered with the hub;

using information in the updated hub registration table at the sending spoke to encrypt traffic to be sent to the receiving spoke without accessing the hub; and

means for sending the encrypted traffic directly to a receiving spoke without sending the encrypted traffic via the hub.

19. The apparatus as claimed in claim 18 including means for using information in the updated hub registration table at a receiving spoke to decrypt traffic received from the sending spoke without accessing the hub and means for determining if a tunnel has been established with the receiving spoke.

20. The apparatus as claimed in claim 18 including means for determining if a tunnel has been established with the receiving spoke.

21. The apparatus as claimed in claim 18 including means for obtaining a subnet and a corresponding public key value of the receiving spoke from the updated hub registration table at the sending spoke without accessing the hub, means for combining the public key value of the receiving spoke with a private key value of the sending spoke to form an encryption key, means for using the encryption key to create a tunnel to the receiving spoke, and means for sending the encrypted traffic via the tunnel without transiting the hub.

22. The apparatus as claimed in claim 18 wherein the means for registering a spoke with a hub further including means for providing spoke registration information including an IP address, a subnet, and a public key value for a registering spoke.

23. An apparatus comprising:

means for receiving encrypted traffic from a first spoke;

means for determining if a tunnel has been established between the first spoke and a second spoke; and

if a tunnel has not been established between the first spoke and the second spoke, means for obtaining an IP address of the first spoke and a corresponding public key value of the first spoke from a hub registration table at the second spoke without accessing the hub, means for combining the public key value of the first spoke with a private key value of the second spoke to form a decryption key, means for using the decryption key to create a tunnel between the first spoke and the second spoke, and means for using information in the hub registration table at the second spoke to decrypt traffic received from the first spoke without accessing the hub, the information in the hub registration table at the second spoke including information sufficient to decrypt traffic received from the first spoke even if the second spoke has not previously received traffic from the first spoke since the second spoke registered with the hub, the encrypted traffic being received directly from the first spoke at the second spoke without being sent via a hub.

24. The apparatus as claimed in claim 23 wherein the hub maintains the hub registration table, the apparatus further including means for receiving an updated copy of the hub registration table at the second spoke.

25. The apparatus as claimed in claim 23 wherein the encrypted traffic is encrypted using a Diffie-Hellman key.

26. An article of manufacture comprising at least one non-transitory machine readable storage medium having one or more computer programs stored thereon and operable on one or more computing systems to:

register a spoke with a hub;

update a hub registration table with spoke registration information;

send the updated hub registration table to a plurality of registered spokes;

use information in the updated hub registration table at a sending spoke to resolve an address of a receiving spoke without accessing the hub, the information in the updated hub registration table at the sending spoke including information sufficient to resolve the address of the receiving spoke even if the sending spoke has not previously sent traffic to the receiving spoke since the sending spoke registered with the hub;

use information in the updated hub registration table at the sending spoke to encrypt traffic to be sent to the receiving spoke without accessing the hub; and

send the encrypted traffic directly to a receiving spoke without sending the encrypted traffic via the hub.

27. The article of manufacture as claimed in claim 26 being further operable to determine if a tunnel has been established with the receiving spoke and, if a tunnel has not been established with the receiving spoke, obtaining a subnet and a corresponding public key value of the receiving spoke from the updated hub registration table at the sending spoke without accessing the hub, combining the public key value of the receiving spoke with a private key value of the sending spoke to form an encryption key without accessing the hub, using the encryption key to create a tunnel to the receiving spoke, and sending the encrypted traffic via the tunnel without transiting the hub.

28. An article of manufacture comprising at least one machine readable storage medium having one or more computer programs stored thereon and operable on one or more computing systems to:

receive encrypted traffic from a first spoke;

determine if a tunnel has been established between the first spoke and a second spoke; and

if a tunnel has not been established between the first spoke and the second spoke, obtain an IP address of the first spoke and a corresponding public key value of the first spoke from a hub registration table at the second spoke without accessing the hub, combine the public key value of the first spoke with a private key value of the second spoke to form a decryption key, use the decryption key to create a tunnel between the first spoke and the second spoke, and use information in the hub registration table at the second spoke to decrypt traffic received from the first spoke without accessing the hub, the information in the hub registration table at the second spoke including information sufficient to decrypt traffic received from the first spoke even if the second spoke has not previously received traffic from the first spoke since the second spoke registered with the hub, the encrypted traffic being received directly from the first spoke at the second spoke without being sent via a hub.

29. The article of manufacture as claimed in claim 28 wherein the encrypted traffic is encrypted using a Diffie-Hellman key.

30. A system comprising:

a hub to retain a hub registration table; and

one or more spokes in data communication with the hub via a network, the spokes being programmed to;

register with the hub;

receive an updated hub registration table from the hub;

use information in the updated hub registration table at a sending spoke to resolve an address of a receiving spoke without accessing the hub, the information in the updated hub registration table at the sending spoke including information sufficient to resolve the address of the receiving spoke even if the sending spoke has not previously sent traffic to the receiving spoke since the sending spoke registered with the hub;

use information in the updated hub registration table at the sending spoke to encrypt traffic to be sent to the receiving spoke without accessing the hub; and

send the encrypted traffic directly to a receiving spoke without sending the encrypted traffic via the hub.

31. The system according to claim 30 being further operable to determine if a tunnel has been established with the receiving spoke and, if a tunnel has not been established with the receiving spoke, obtaining a subnet and a corresponding public key value of the receiving spoke from the updated hub registration table at the sending spoke without accessing the hub, combining the public key value of the receiving spoke with a private key value of the sending spoke to form an encryption key without accessing the hub, using the encryption key to create a tunnel to the receiving spoke, and sending the encrypted traffic via the tunnel without transiting the hub.