Local peer to peer direct connection in network address translator (NAT) and overlay networks

In a method of Local Peer to Peer Direct Connection in NAT and overlay network. A request is received from a first peer at a relay gateway to establish a direct connection with a second peer. The first peer and the second peer are located behind a NAT firewall. An authentication request is relayed from the first peer at the relay gateway. The authentication request is forwarded from the relay gateway to the second peer. Upon performing authentication at the second peer, an authentication response is received at the relay gateway. The authentication response is received from the relay gateway at the first peer. An internal route propagation is performed from the second peer to the first peer via the relay gateway. A Local Peer to Peer Direct Connection is established between the first peer and the second peer for packet flow through the direct connection.

BACKGROUND

Network address translation (NAT) is the process of modifying the IP source address and optionally the source port information in Layer 3/Layer 4 packet header so that packets can be routed to the required destination and the response if any can reach the connection initiator. NAT is used in routers to allow a number of devices each with their own private network address to connect to the public Internet. The combination of the NAT process along with routers also acting as firewalls is referred to as NAT firewall. This solution is useful in the context of two peers trying to establish a securely overlay connection with each other in a NAT environment. There are two basic means of data flow between peers in an overlay network namely, direct connection and indirect connection. In direct connection mode, the peers exchange packets directly via an IP network. In indirect connection mode, the packets get forwarded via an intermediary gateway with a pre-configured, public IP address and port. NAT/firewall traversal aided by the gateway leads to direct connection between peers if the NAT/firewalls are endpoint independent.

In this peer to peer direct connection (PPDC) the route gateway then aids the peers in discovering each other's internal and external address. PPDC requires at least one of the peer be behind a NAT and configured in one of the modes such as restricted cone, address restricted cone and port restricted cone. NAT firewall traversal using a route gateway is not possible if at least one of (a) NATs are not endpoint independent and (b) UDP hole punching is not allowed by the firewall. PPDC uses Session traversal utilities for NAT (STUN), a standardized set of methods for traversal of NAT gateways. STUN helps connect end points determine each other's public IP address. In peer to peer indirect connection (PPIC), a relay gateway lets peers behind NATs discover each other and establish an indirect connection. Indirect connection has various disadvantages such as the gateway acting as a bottleneck during packet transfer, gateway going down disrupts connectivity, etc. PPIC uses a set of methods collectively known as Traversal Using Relay around NAT (TURN). Session traversal utilities for NAT (STUN) is a standardized set of methods for traversal of NAT gateways.

DETAILED DESCRIPTION

Embodiments of techniques of Local Peer to Peer Direct Connection in NAT and overlay network are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of the embodiments. A person of ordinary skill in the relevant art will recognize, however, that the embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In some instances, well-known structures, materials, or operations are not shown or described in detail.

FIG. 1is a block diagram illustrating high level architecture of a system100for Local Peer to Peer Direct Connection in NAT and overlay network, according to one embodiment. In a peer to peer overlay networks, hosts or clients initiate sessions to peer nodes and also accept sessions initiated by peer nodes. An endpoint is a session-specific IP address: port tuple on the host or client. The overlay endpoint residing on a particular host is represented differently for each IP protocol viz. IPv4 and IPv6. Furthermore, the endpoints for each overlay that a host participates in have different IP and port tuples. When a client such as peer A102in a private network initiates an outgoing session to another client such as peer B104in the public network through a NAT device such as NAT firewall106, the NAT firewall10assigns a public endpoint to translate the private endpoint so that subsequent response packets from the external client can be received by the NAT, translated, and forwarded to the private endpoint. This mapping is performed for the duration of the session. The NAT device filters out packets not destined to the internal address associated with the peer B104such as X:x, where X represents the IP address and x represents the port. Peer to peer application is designed to work effectively even as peering nodes are located in distinct IP address networks, connected by one or more NATs. There are various methods of implementing peer-to-peer communication in the presence of a NAT device, however, the most reliable method is to make the peer-to peer communication like a client/server communication through relaying.

The most reliable method of peer to peer communication across NAT is to make the communication look to the network like standard client/server communication, through relaying. Suppose two clients such as peer A102and peer B104have each initiated TCP or UDP connections to a gateway108, at the gateway's global IP address and port number. The peers may reside on separate private networks, and their respective NATs prevent either peers from directly initiating a connection to the other. If the direct connection attempt fails, the peers can use the gateway,108to relay messages. For example, to send a message to peer B104, peer A102sends the message to the gateway108along its already-established client/server connection, and the gateway108forwards the message on to peer B104using its existing client/server connection with peer B104. Relaying works as long as both peers can connect to the gateway108.

FIG. 2is a flowchart illustrating Local Peer to Peer Direct Connection in NAT and overlay network, according to one embodiment. Peer A202is behind NAT firewall204and peer B206is behind NAT firewall208. When a peer in a private network initiates an outgoing session to a client in the public network through a NAT device, the NAT device assigns a public endpoint to translate the private endpoint so that subsequent response packets from the external client can be received by the NAT, translated, and forwarded to the private endpoint. This mapping is performed for the duration of the session. The NAT filters out packets not destined to the internal address associated with the client such as peer A202‘10.0.200.5:20000’, where ‘10.0.200.5’ represents the IP address of peer A202and ‘20000’ represents the port. Peer B206is at ‘2.2.2.3:35000’, where ‘2.2.2.3’ represents the IP address of peer B206and ‘35000’ represents the port. At210, connection from peer A202‘10.0.200.55:5000’ is not allowed on peer B206‘2.2.2.3:35000’. The peer A202and peer B206reside on separate private networks, and their respective NATs prevent either peer from directly initiating a connection to the other. Instead of attempting a direct connection, the two peers use relay gateway212to relay messages between them. At210, first step authentication is performed, from peer A202‘10.0.200.55:5000’ an authentication request via relay214is sent to the relay gateway212. The authentication request is forwarded216from the relay gateway212to the peer B206. The peer B206authenticates the request received, and the authentication response is forwarded218from the peer B206to the relay gateway212. The authentication response is forwarded220from the relay gateway212to the peer A202. This process is referred to as peering, since a voluntary interconnection is established between the peers behind respective NAT. An agreement by two or more networks to peer is instantiated by a physical interconnection of the networks, an exchange of routing information through the relay gateway212establishes a connection between the peers.

The connection established between the peers may be an encrypted path. Using an encryption algorithm with inputs such as secret key ‘K’ and the peer B206at 10.0.100.35:2000 is provided222to establish the encrypted path. The encrypted path is established from peer B206to the relay gateway214at the IP address ‘10.0.100.35’ and the port ‘2000’. This is referred to as internal route propagation. The established encrypted path is forwarded224from the relay gateway214to the peer A202. At226, a direct connection request is sent on the established encrypted path at ‘10.0.100.35:2000’ from the peer A202to peer B206. At228, the peer B206connection is accepted and the connection acceptance information is sent from peer B206to the peer A202. At230, once the direct connection is established, packet or message flow is directly sent and received between the peer A202and the peer B206. For example, to send a message to peer B206, peer A202simply sends the message directly in the already-established client/server connection.

FIG. 3illustrates a use case for generic deployment in NAT and overlay network, according to one embodiment. Nodes or clients or peers on private networks can connect to other nodes on the same private network, and they can usually open TCP or UDP connections to “well-known” nodes in the global address realm. NATs on the path allocate temporary public endpoints for outgoing connections, and translate the addresses and port numbers in packets comprising those sessions, while generally blocking all incoming traffic unless otherwise specifically configured. A session endpoint for TCP or UDP is an (IP address, port number) pair, and a particular session is uniquely identified by its two session endpoints. The direction of a session is normally the flow direction of the packet that initiates the session: the initial SYN packet for TCP, or the first user datagram for UDP. Of the various flavors of NAT, the most common type is traditional or outbound NAT, which provides an asymmetric bridge between a private network and a public network.

NATs by default allows only outbound sessions to traverse the NAT: incoming packets are dropped unless the NAT identifies them as being part of an existing session initiated from within the private network. Outbound NAT conflicts with peer-to-peer protocols because when both peers desiring to communicate are “behind” (on the private network side of) two different NATs, whichever peer tries to initiate a session, the other peer's NAT rejects it. NAT traversal entails making peer to peer sessions look like “outbound” sessions to both NATs. Outbound NAT has two sub-varieties: Basic NAT, which only translates IP addresses, and Network Address/Port Translation (NAPT), which translates entire session endpoints.

The private network office302includes devices such as device A304and a router306. The private network office302is behind a NAT firewall308. Relay gateway310and the device B312are in public IP314network behind a NAT firewall316. Amazon Web Service (AWS)318is a cloud private network that includes device C320and device D322behind NAT firewall324. Suppose node router306wants to establish a direct connection with device D322, and the direct connection may be a TCP or UDP connection. The router306does not know the existence of device D322, and therefore the relay gateway310that is reachable in the public IP314is contacted by the router306to establish a connection with the device D322. The router306initiates an authentication request via relay mode to the gateway310. The gateway310forwards the authentication request to the device D322. The device D322authenticates the request received from the router306and send an authentication response to the router306via the relay gateway310. Peering between the router306and the device D322is established by using the symmetric encryption algorithm for establishing an encryption path from the router306to the device D322.

The encrypted route is forwarded to the router306. A direct connection request is sent from the router306to the device D322. To enable direct communication between two devices or peers when they are behind NAT/NAT firewall and the relay gateway310is on the other side of the NAT/NAT firewall is performed by propagating internal routes to the peers or devices. Internal route propagation happens only when direct route has not been established between the peers at the end of the authentication step. Once the direct connection is established between the router306and the device D322, the packet exchanges takes place directly between the device D322D and the router306.

FIG. 4illustrates a use case for generic deployment in NAT and overlay network, according to one embodiment. Consider a scenario where peer A402is behind NAT-A404, here the private IP address of peer A402is ‘192.168.50.5:5000’ and the public IP address of peer A402is ‘2.2.2.2:3500’. Peer B406is behind NAT-B408, here the private IP address of peer B406is ‘10.0.200.55:2500’ and the public IP address of peer B406is ‘4.4.4.4:50000’. Gateway410is outside both the NAT-A404and NAT-B408, and the gateway410may be behind NAT-C412. Peer A402may not directly connect with peer B406.

Traversal using relay NAT (TURN) is a protocol that assists in traversal of NAT or firewalls for multimedia applications using TCP and UDP protocol. TURN allows a client to obtain IP addresses and ports from such a relay. Gateway410generates a peer table414with IP address and port information of the peers communicating with the gateway410. When the peer A402attempts to establish a connection with peer B, it is not allowed. Hence, peer A402send an authentication request via relay mechanism to the gateway410, and the gateway410forwards the authentication request to the peer B406. When the authentication request is received from the peer A402, the gateway410makes an entry of the public IP address ‘2.2.2.2:3500’ of the peer A402in the peer table414as shown in row416. The peer B406performs authentication of the peer A402, and the response to the authentication request is forwarded to the peer A402. When the authentication response is received from the peer B406, the gateway410makes an entry of the public IP address ‘4.4.4.4:50000’ of the peer B406in the peer table414as shown in row418. The updated peer table414is propagated from the gateway410to the peer A402and the peer B406.

Once peer A402is authenticated by peer B406, a symmetric encryption is performed by peer B406using a symmetric key to establish an encrypted authenticated path between the peer B406and the peer A402. The peer B406propagates its private IP address ‘10.0.200.55:2500’ through the established encrypted authenticated path to the peer A402, and this is referred to as internal route propagation. When the peer A402receives the private IP address ‘10.0.200.55:2500’ of the peer B406, a direct connection request is sent from peer A402to peer B406using the private IP address of peer B406. Once the direct connection is established between the peer A402and the peer B406, the packets and messages are sent between the peer A402and the peer B406directly without an intermediate gateway410. Here, the network could operate in a headless mode when the gateway410goes offline, where the peer A402and the peer B406directly communicate with each other.

FIG. 5illustrates a use case for Local Peer to Peer Direct Connection in NAT and overlay network, according to one embodiment. Consider a scenario where both peer A502and peer B504are behind the same NAT-A firewall506and a gateway508is behind a different NAT-B firewall510. The peer A502is behind the NAT-A firewall506, here the private IP address of peer A502is ‘10.0.200.55:5000’ and the public IP address of peer A502is ‘2.2.2.2:40000’. Peer B504is also behind the same NAT-A firewall506, here the private IP address of peer B506is ‘10.0.100.35:2000’ and the public IP address of peer B506is ‘2.2.2.3:35000’. Gateway508is behind NAT-B510. Peer A402may not directly connect with peer B406.

Gateway508generates a peer table512with IP address and port information of the peers communicating with the gateway508. When the peer A502attempts to establish a connection with peer B504, it is not allowed. Hence, peer A502send an authentication request via relay mechanism to the gateway508, and the gateway508forwards the authentication request to the peer B504. When the authentication request is received from the peer A502, the gateway508makes an entry of the public IP address ‘2.2.2.2:4000’ of the peer A502in the peer table512as shown in row514. The peer B504performs authentication of the peer A502, and the response to the authentication request is forwarded to the peer A502. When the authentication response is received from the peer B504, the gateway508makes an entry of the public IP address ‘2.2.2.3:35000’ of the peer B504in the peer table512as shown in row516. The updated peer table512is propagated from the gateway508to the peer A502and the peer B504.

Once the peer A502is authenticated by peer B504, a symmetric encryption is performed by peer B504using a symmetric key to establish an encrypted authenticated path between the peer B504and the peer A502. The peer B504propagates its private IP address ‘10.0.100.35:2000’ through the established encrypted authenticated path to the peer A502, and this is referred to as internal route propagation. The public IP address ‘2.2.2.3:35000’ of peer B504is updated in the peer table512and the peer table512is propagated from the gateway508to the peer A502. When the peer A502receives the private IP address ‘10.0.100.35:2000’ of the peer B504, a direct connection request is sent from peer A502to peer B504using the private IP address of peer B504. The public IP address ‘2.2.2.2:40000’ of peer A502is updated in the peer table512and the peer table512is propagated from the gateway508to the peer B504. Once the direct connection is established between the peer A502and the peer B504, the packets and messages are transferred between the peer A502and the peer B504directly without an intermediate gateway508. Here, the network could operate in a headless mode when the gateway508goes offline, where the peer A502and the peer B504directly communicate with each other. Therefore, the connection which was initially an indirect connection request between the peers via the gateway508, eventually switches to a direct mode connection between the peers.

FIG. 6is flowchart600illustrating method of Local Peer to Peer Direct Connection in NAT and overlay network, according to one embodiment. At602, a request is received from a first peer at a relay gateway to establish a direct connection with a second peer. The first peer and the second peer are located behind a NAT firewall. At604, an authentication request is relayed from the first peer at the relay gateway. At606, the authentication request is forwarded from the relay gateway to the second peer. Upon performing authentication at the second peer, at608, an authentication response is received at the relay gateway. At610, the authentication response is received from the relay gateway at the first peer. At612, an internal route propagation is performed from the second peer to the first peer via the relay gateway. At614, a Local Peer to Peer Direct Connection is established between the first peer and the second peer for packet flow through the direct connection.

Local Peer to Peer Direct Connection in NAT'd and overlay network has the following advantages. It eliminates the gateway as the bottleneck once a direct connection is established between the peers. The bottleneck manifests even with a single packet. The gateway is essentially dealing with two packets (one inbound and the other outbound). It gets accentuated when encryption and decryption is involved and gets magnified manifold when there are many peers communicating simultaneously via the gateway. Relay gateway going down does not disrupt connectivity between peers. Peers can operate in headless mode even as the gateway is brought back online. Relay gateway does not need to see (decrypt and re-encrypt) all packets. This enhances the security further.

FIG. 7is a block diagram illustrating a computing system700consistent with implementations of the current subject matter. As shown inFIG. 7, the computing system700can include a processor702, a memory704, network communicator706, a storage device708, and input/output devices710. The processor702, the memory704, network communicator706, the storage device708, and the input/output device710can be interconnected via a system bus712. The processor702is capable of processing instructions for execution within the computing system700. Such executed instructions can implement one or more components of, for example, application A. In some example embodiments, the processor702can be a single-threaded processor. Alternately, the processor702can be a multi-threaded processor. The processor702is capable of processing instructions stored in the memory704and/or on the storage device708to display graphical information for a user interface provided via the input/output device710.

The memory704is a computer readable medium such as volatile or non-volatile that stores information within the computing system700. The memory704can store instructions and/or other data associated with the processes disclosed herein. The storage device708is capable of providing persistent storage for the computing system700. The storage device708can be a hard disk device, an optical disk device, or a tape device, or other suitable persistent storage means. The input/output device710provides input/output operations for the computing system700. In some example embodiments, the input/output device710includes a keyboard and/or pointing device. In various implementations, the input/output device710includes a display unit for displaying graphical user interfaces.

According to some example embodiments, the input/output device710can provide input/output operations for a network device. For example, the input/output device710can include Ethernet ports or other networking ports to communicate with one or more wired and/or wireless networks (e.g., a local area network (LAN), a wide area network (WAN), the Internet).

The above descriptions and illustrations of embodiments, including what is described in the Abstract, is not intended to be exhaustive or to limit the one or more embodiments to the precise forms disclosed. While specific embodiments of, and examples for, the one or more embodiments are described herein for illustrative purposes, various equivalent modifications are possible within the scope, as those skilled in the relevant art will recognize. These modifications can be made in light of the above detailed description. Rather, the scope is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.