Mechanisms for role negotiation in the establishment of secure communication channels in peer-to-peer environments

• US 20090276537A1
• Filed: 12/17/2008
• Published: 11/05/2009
• Est. Priority Date: 12/20/2007
• Status: Abandoned Application

• Current Assignee: Ooma Incorporated
• Original Assignee: Ooma Incorporated
• Inventors: Bryan, Marcia Z., Broadbent, Tiffany L., Deverick, James W.
• Application Number:
  US12/317,077
• Publication Number:
  US 20090276537A1
• Time in Patent Office: Days
• US Class Current: 709/237
• CPC Class Codes: H04L 63/061 for key exchange, e.g. in peer-to-peer networks cryptographic mechanisms or cryptographic arrangements for key agreement H04L9/0838
• CPC Class Codes: H04L 63/166 at the transport layer
• CPC Class Codes: H04L 67/104 Peer-to-peer [P2P] networks
• CPC Class Codes: H04L 67/14 Session management for real-time applications in data packet communications networks H04L65/1066
• CPC Class Codes: H04L 69/24 Negotiation of communication capabilities

Abstract

A method of establishing secure communication channels in peer-to-peer environments is provided, that includes eliminating a role conflict between at least first peer and a second peer, determining which the peer will act as a client and which the peer will act as a server in a secure connection handshake, and when the first peer or the second peer detects a role conflict an attribute of the handshake message is used as a tiebreaker to determine a wait period, where the first peer or the second peer cancels its own requests, drops an incoming request or denies an incoming request and waits a random amount of time before resending the connection request, where a random time interval used by the peers can be different to reduce a chance for role conflict.

Claims

1. A method of establishing secure communication channels in peer-to-peer environments comprising:

a. eliminating a role conflict between at least first peer and a second peer, wherein said first peer will cancel an existing request and drop or deny the incoming request, wherein said first peer will wait a random amount of time, and then retry the secure connection request if a secure connection has not already been established with said second peer;

b. determine which said peer will act as a client and which said peer will act as a server in a secure connection handshake, wherein when said first peer becomes said server a secure connection request is canceled by said first peer and a response is sent back to said second peer'"'"'s request, wherein when said second peer becomes said client an incoming request is dropped or denied by said second peer and said second peer waist for a response to its request, wherein if a tie cannot be broken, said incoming request should be dropped or denied and said first peer or said second peer should generate a new request with a new tiebreaker value; and

c. when said first peer or said second peer detects a role conflict an attribute of the handshake message is used as a tiebreaker to determine a wait period, wherein said first peer or said second peer cancels its own requests, drops an incoming request or denies an incoming request and wait a random amount of time before resending the connection request, wherein a random time interval used by said peers can be different to reduce a chance for role conflict.