US20190306116A1 - Multiplexing security tunnels - Google Patents
Multiplexing security tunnels Download PDFInfo
- Publication number
- US20190306116A1 US20190306116A1 US15/937,831 US201815937831A US2019306116A1 US 20190306116 A1 US20190306116 A1 US 20190306116A1 US 201815937831 A US201815937831 A US 201815937831A US 2019306116 A1 US2019306116 A1 US 2019306116A1
- Authority
- US
- United States
- Prior art keywords
- tunnel
- packets
- cloud
- gateway
- ipsec
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
-
- 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
- H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
-
- 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
-
- 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/2514—Translation of Internet protocol [IP] addresses between local and global IP addresses
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/2592—Translation of Internet protocol [IP] addresses using tunnelling or encapsulation
Definitions
- IP Internet Protocol
- IPSec Internet Protocol Security protocol
- IPSec tunnels is straightforward for a pair of subnets (virtual or logical) and respective directly communicating gateways.
- administrators may deploy many subnets on different clouds, each potentially providing communication with the others across the Internet.
- Each cloud may host multiple tenant subnets and assign its own pool of gateways to secure traffic to/from these subnets.
- these gateways may have to share a limited number of Internet-routable IP addresses.
- these gateways are deployed behind some kind of network multiplexor, which multiplexes the traffic between the different gateways. That is, a multiplexor may help multiple gateways with private addresses share a small pool of Internet addresses.
- the second problem discovered by the inventors stems from the fact that the different IPsec tunnels connecting the various tenant subnets among the Internet-separated clouds are tightly coupled with a specific pair of gateways. All IPsec traffic—both control (IKE) and data (Encapsulating Security Payload (ESP)/Authentication Header AH)) exchanges must always be routed between the gateway devices associated with the tunnels; at each end, the same gateway must handle all of a given tunnel's traffic, even if they might otherwise be interchangeable with respect to routing. But when the gateways share multiplexed Internet addresses, the IPsec traffic for different tunnels would be indistinguishable from each other at the network layer, as the datagram IP addresses would be same for all such packets. As the Inventors have observed, this creates ambiguity in how the packets are routed to the appropriate Gateway devices and until now prevents address sharing.
- IKE control
- ESP Encapsulating Security Payload
- AH Authentication Header AH
- Embodiments relate to enabling clouds to multiplex their public network addresses among private addresses of IPSec gateways while making sure that IPSec tunnel packets are delivered to the private addresses of the IPSec tunnels that they are associated with.
- the cloud may determine which IPSec tunnel or gateway the IPSec packets are associated with and modify the IPSec packets to identify the associated tunnel or gateway.
- the cloud may find identity information in the IPSec packets that identifies the associated tunnel or gateway (or security policy). The identity information is used to direct the IPSec packets to the associated tunnel or gateway.
- FIG. 1 shows a first pair of IPSec gateways.
- FIG. 2 shows a process by which a tunnel can be identified when its packets traverse a network using shared network addresses.
- FIG. 3 shows where tunnel identification can occur.
- FIG. 4 shows an embodiment for two different clouds that communicate via a common network.
- FIG. 5 shows how static port numbers of tunnel packets can be used to add identification to site-to-site tunnel related communications.
- FIG. 6 shows how a second packet completes the initiation shown in FIG. 5 .
- FIG. 7 shows details of a computing device on which embodiments described above may be implemented.
- FIG. 1 shows a first pair of IPSec gateways 100 , 102 (GW-A 1 , GW-A 2 ) communicating via a network 104 with a second pair of IPSec gateways 106 , 108 (GW-B 1 , GW-B 2 ).
- the first pair of gateways 100 , 102 share an Internet-routable IP address—VIP A .
- VIP A is multiplexed by a first multiplexor 110 .
- Multiplexor 110 may use network address translation (NAT) techniques to translate inbound traffic to the correct addresses of the gateways behind it and to translate outbound traffic to the shared address VIP A .
- the second pair of gateways share another Internet-routable IP address—VIP B .
- NAT network address translation
- VIP B is multiplexed by a second multiplexor 112 .
- Multiplexor 112 allows the second gateways to share VIP B by translating inbound traffic addressed to VIP B to the addresses of the second gateways and translating the addresses of the second gateways' outbound traffic to the shared address VIP B .
- the gateways implement the IPSec protocol to provide site-to-site tunnels, absent embodiments described herein, the following problems arise.
- the first multiplexor 110 may receive from the second multiplexor 112 an IPSec datagram 1 intended for a first tunnel 116 associated with the first gateway 100 .
- the first multiplexor also receives a second datagram 2 from the second multiplexor 112 that is intended for a second tunnel 118 associated with the other first gateway 102 .
- the first multiplexor must decide whether to pass it to first gateway 100 or first gateway 102 .
- the same is true for datagram 2 which gateway to address it to.
- datagram 1 and datagram 2 are indistinguishable, from a network layer perspective.
- the multiplexor has no way to know which gateway should receive which datagram.
- the IPSec protocol specifies that the endpoints of a tunnel form an SA and the tunnel must flow through only those securely associated endpoints.
- the security association is, in effect, between the network addresses of the endpoints.
- a gateway will decide which datagrams belong to which tunnels based on “to” and “from” IP addresses of the datagrams.
- the first multiplexor 110 receives datagrams that have the same “to” and “from” addresses VIP A /VIP B .
- the first multiplexor 110 has no way to determine which SA or gateway the inbound datagrams belong to.
- the second multiplexor 112 has the same problem.
- the second multiplexor may have no way of determining which gateway datagram 3 and datagram 4 should go to, or which tunnel or tenant they are associated with.
- FIG. 2 shows a process by which a tunnel can be identified when it traverses a network using shared network addresses (e.g., public IP addresses).
- shared network addresses e.g., public IP addresses.
- the initiator of a communication exchange whether for an IKE transmission or and ESP/HA transmission (referred to as IPSec communications/packets hereafter), to inject into its IPSec communication an identifier for the relevant tunnel that can be used on the receiving side to differentiate between tunnels. Note that such marking can be used to identify a particular gateway or tenant, as these three entities are somewhat equivalent. Description will refer to tunnels with the understanding that other entities may be identified.
- first gateway 100 is to initiate an IPSec communication, either for sending data or negotiating an SA.
- the first gateway 100 receives a host or tenant packet to use or establish a site-to-site IPSec tunnel.
- the first gateway 100 has a corresponding original tunnel packet that is publicly addressed to remote second multiplexor 112 (addressed to VIP B ).
- the first gateway transmits the original tunnel packet to an internal interface of the first multiplexor.
- the first multiplexor receives the original tunnel packet.
- the first gateway recognizes the tunnel packet and consequently proceeds to modify the tunnel packet to include indicia of the corresponding tunnel.
- the first multiplexor cannot directly control how the remote end responds, by including an identifier for the target tunnel, the sender enables the remote end to identify the target tunnel if it is appropriately configured etc.
- the second multiplexor 112 receives the tunnel packet.
- the second multiplexor reads the tunnel identifier and selects the corresponding gateway (how this can be done is described below). For example, if the packet is marked as being for a particular tunnel, tenant, or gateway, the multiplexor, in addition to performing functions necessary for address-multiplexing, may modify the tunnel packet to assure that it is delivered to the appropriate gateway and, in some embodiments, to allow the receiving gateway to determine which tunnel the packet is associated with.
- the multiplexor 112 may modify the tunnel packet to assure that it is delivered to the appropriate gateway and, in some embodiments, to allow the receiving gateway to determine which tunnel the packet is associated with.
- the multiplexors may maintain or access mapping information 138 which can be used to map the tunnel identifiers to the tunnel identifiers in the tunnel packets exchanged over the common network 104 .
- the mapping information 138 may depend on how the tunnel identifiers are derived and/or are embedded in the tunnel packets. In some embodiments, mapping information is not needed and the opposing ends rely on conventions, static identifiers, combinations of header/packet information, etc.
- FIG. 3 shows where tunnel identification can occur.
- tunnel packet modification 148 may be performed at any point at or after a gateway (since an IPSec packet is formed at the gateway) and up to transmission to the common network. That is, packet marking or transformation can be done at any point before a packet leaves a cloud (for outbound packets) or at any point after a packet enters a cloud (for inbound packets).
- a bump-in-the-line device or proxy server can be transparently employed, before or after the multiplexing device.
- the gateways may be provided with modules for modifying tunnel packets.
- FIG. 4 shows an embodiment for two different clouds that communicate via the common network 104 .
- Cloud A 150 may have one or more first IP addresses 152 that are shared among first gateways 100 , 102 .
- the cloud A gateways share at least VIP A .
- First gateway 100 has an internal address DIP A1
- first gateway 102 has an internal address DIP A2 .
- cloud B 154 may multiplex one or more IP addresses 156 , including at least VIP B , which is shared among the second gateways 106 , 108 .
- the gateways of the clouds may provide routing for private tenant subnets from which tunnels and traffic carried thereby originate.
- FIG. 5 shows how static port numbers of tunnel packets can be used to add identification to site-to-site tunnel related communications.
- the example of FIG. 5 is for an IKE SA negotiation, although extension of the technique to other exchanges will be apparent.
- cloud A determines that a first tunnel 116 (T 1 ) is needed
- the first gateway 100 sends a first packet 170 to the first multiplexor 110 (or other point as mentioned above).
- the first multiplexor 110 recognizes the first packet 170 as an IKE packet, the first multiplexor decides what identifier to use for the corresponding tunnel.
- the identifier is “X”, which could be any valid practical port number.
- the first multiplexor replaces the “from” port “ 500 ” in the first packet with “X” and changes the “from” address from DIP A1 to VIP A .
- the modified first packet 172 is then transmitted from an interface for VIP A .
- the modified first packet 172 is routed through the common network 104 to the second multiplexor 112 .
- the second multiplexor 112 receives the modified second packet 172 .
- the modified second packet 172 is analyzed and recognized as a tunnel packet (an IKE packet, in this example). Consequently, the tunnel identifier is extracted from the modified first packet 172 .
- the port number is helpful for identifying a tunnel, the addresses of the modified first packet 172 may also help to identify the tunnel.
- the second multiplexor 112 recognizes the identifier and, according thereto, determines which gateway in cloud B the modified first packet should be addressed to, namely, DIP B2 for second gateway 106 .
- the second multiplexor 112 maps the identifier (port X in this case) to the correct gateway instance.
- the packet is updated with the address of the correct gateway (second gateway 106 ).
- the second multiplexor 112 then transmits the again-modified first packet from an internal interface to the second gateway 106 .
- the second gateway is 106 is assured that it has received a packet for an SA attached/attaching to the second gateway 106 .
- the use of “from” data to identify the tunnel enables the first packet to be properly routed through the common network but also carry additional information about the tunnel or gateway that can be used by cloud B.
- the port number “X” in FIG. 5 can be statically or dynamically determined by the sending side. In the static case, both ends know in advance which ports correspond to which tunnels, tenants, or gateways. The ports may be pre-configured in security policies, and when the SA is negotiated. Specifically, with the static port approach, when tunnel T 1 is configured between VIP A and VIP B the port X is read from a policy and an associated NAT rule is configured to point to DIP B2 of GW-B 2 . In the dynamic port approach, a hash may be computed of the 3-tuple (source IP, source port, and destination IP), and the hash resolves to DIP B 2 of GW-B 2 .
- the incoming modified first packet is translated to be addressed to the correct gateway address—DIP B 2 .
- the thus-transformed packet indicates the need for IKE service.
- the IKE service is required to receive packets from any remote port and must send its response to the same remote port (X in this case), thus maintaining the port-tunnel association on both ends.
- the port reservation is dynamic in nature and is associated by the NAT (or equivalent component) to a particular gateway. Since multiple tunnels may terminate on the same gateway, such ports are not unique to a tunnel. But, it is unique to a gateway, across all gateways in a cloud deployment.
- the dynamic port approach implicitly assumes that every gateway device is configured with policies for all tunnels in that cloud deployment.
- FIG. 6 shows how a second packet 180 completes the initiation shown in FIG. 5 .
- the responder in the second gateway 106 uses NAT detection in the IKE message (per section 2.23 in RFC 7296) and determines that the first and second gateways are behind a NAT layer, and consequently switches to using UDP port “4500” for future IKE messages.
- the second gateway 106 creates a second packet 180 , in this example, the response to the SA initialization packet from cloud A.
- the outbound second packet 180 is intercepted by the second multiplexor 112 , which recognizes the source and port and translates the second packet 180 to a modified second packet 182 by changing: the “from” address from the second gateway's (DIP B2 ) to that of the multiplexed public address of cloud B (VIP B ), the “from” port from “4500” to “X”, and the “to” port from “X” to “4500”.
- the modified second packet 182 is then transmitted over the common network from the interface for VIP B to the interface for VIP A .
- Cloud A receives the modified second packet 182 (the IKE_SA_INIT response) in the same way that cloud B received the modified first packet, ultimately delivering the response to the correct gateway for the identified, tunnel, i.e., the first gateway 100 .
- Data packets will also be encapsulated with UDP:4500. See RFC 7295, section 2.23 explaining why ESP packets would be UDP encapsulated.
- Data packets (UDP encapsulated ESP) will be transformed as follows, where “ ⁇ ” denotes a translation at a cloud, and where “ ⁇ a:b, c:d ⁇ ” denotes “from address a:port b, and to address c:port d”, and where the packets are marked as UDP encapsulated ESP packets.
- the second tunnel T 2 may be handled as follows.
- second gateway 106 (GW-B 1 ) in cloud B initiates negotiation for the second tunnel T 2 118 .
- port Y that is reserved for NAT-ing.
- all IKE and UDP encapsulated ESP packets for tunnel T 2 118 will have source port Y.
- the other first gateway 102 (GW-A 2 ) in Cloud A is selected for this port.
- all packets for tunnel T 2 will flow between the other first gate 102 (GW-A 2 ) and the second gateway 108 (GW-B 1 ) without interfering with any traffic of tunnel T 1 .
- IPSec exchanges involve a component at the transmitting side adding a tunnel identifier before an outbound tunnel packet is transmitted from a shared address routable on the common network.
- the receiving side can use the identifier to make sure that the tunnel packet goes to the gateway where the corresponding SA has been established.
- a tunnel identifier is to be used to identify each tunnel.
- the Tunnel ID uniquely identifies an IPsec tunnel across all tunnels configured in all gateways in the relevant clouds.
- the tunnel ID may be a globally unique identifier, a friendly string, or computed as a hash of various unique elements of the IKE policy.
- the tunnel ID should be known (or derivable independently) on the two gateways between which a given tunnel is to be established.
- the two involved IKE peers negotiate the IKE SA.
- the initiator selects an IKE policy to use for the tunnel that is being established.
- the NAT port is configured within the IKE policy.
- the IKE responder looks at the 3-tuple (Source IP, Source Port and Destination IP) of the incoming IKE message to find the matching IKE policy.
- the 3-tuple is not guaranteed to be unique to a tunnel in a Gateway.
- the initiator sends a vendor ID payload (section 3.12 of RFC 7296) in the IKE_SA_INIT message.
- the 3-tuple (source IP, source port, destination IP) can be used to uniquely identify the IPsec policy.
- the tunnel ID can be passed to in the IDi (initiator ID) and optional IDr (responder ID) payload to identify the tunnel being established and to choose the appropriate IPsec policy to negotiate the child SA.
- IDi initiator ID
- IDr responder ID
- the ID payloads are used in IKE_SA_AUTH exchange as follows (fields are described in the RFC):
- HDR HDR
- SK ⁇ IDi, [IDr, ]AUTH, SAi2, TSi, TSr ⁇ is sent, and
- HDR HDR
- SK ⁇ IDr AUTH
- SAr2 TSi, TSr ⁇ is sent in reply.
- ID_KEY_ID An opaque octet stream that may be used to pass vendor-specific information necessary to do certain proprietary types of identification.
- the initiator will use this for the IDi payloads.
- the responder will use this ID payload to find the right matching policy, which is used for child SA negotiation and to validate the AUTH payload (for shared secret-based authentication).
- CREATE_CHILD_SA exchanges are used to create new child SAs (of the SA established above) and to rekey both IKE SAs and child SAs. This will use the same pattern as IKE_SA_AUTH exchange.
- FIG. 7 shows details of a computing device 300 on which embodiments described above may be implemented.
- the computing device 300 is an example of a client/personal device or backend physical (or virtual) server devices that may perform various (or perhaps most) of the processes described herein.
- the technical disclosures herein will suffice for programmers to write software, and/or configure reconfigurable processing hardware (e.g., field-programmable gate arrays (FPGAs)), and/or design application-specific integrated circuits (ASICs), etc., to run on the computing device 300 (possibly via cloud APIs) to implement the embodiments described herein.
- reconfigurable processing hardware e.g., field-programmable gate arrays (FPGAs)
- ASICs design application-specific integrated circuits
- the computing device 300 may have one or more displays 322 , a camera (not shown), a network interface 324 (or several), as well as storage hardware 326 and processing hardware 328 , which may be a combination of any one or more: central processing units, graphics processing units, analog-to-digital converters, bus chips, FPGAs, ASICs, Application-specific Standard Products (ASSPs), or Complex Programmable Logic Devices (CPLDs), etc.
- the storage hardware 326 may be any combination of magnetic storage, static memory, volatile memory, non-volatile memory, optically or magnetically readable matter, etc.
- the meaning of the term “storage”, as used herein does not refer to signals or energy per se, but rather refers to physical apparatuses and states of matter.
- the hardware elements of the computing device 300 may cooperate in ways well understood in the art of machine computing.
- input devices may be integrated with or in communication with the computing device 300 .
- the computing device 300 may have any form-factor or may be used in any type of encompassing device.
- the computing device 300 may be in the form of a handheld device such as a smartphone, a tablet computer, a gaming device, a server, a rack-mounted or backplaned computer-on-a-board, a system-on-a-chip, or others.
- Embodiments and features discussed above can be realized in the form of information stored in volatile or non-volatile computer or device readable media. This is deemed to include at least media such as optical storage (e.g., compact-disk read-only memory (CD-ROM)), magnetic media, flash read-only memory (ROM), or any current or future means of storing digital information.
- the stored information can be in the form of machine executable instructions (e.g., compiled executable binary code), source code, bytecode, or any other information that can be used to enable or configure computing devices to perform the various embodiments discussed above.
- RAM random-access memory
- CPU central processing unit
- non-volatile media storing information that allows a program or executable to be loaded and executed.
- the embodiments and features can be performed on any type of computing device, including portable devices, workstations, servers, mobile wireless devices, and so on.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
- When two hosts on different networks are to communicate over an insecure network such as the Internet, those hosts may require their communications to be secured as they transit the insecure network. It may be inconvenient for the hosts themselves to secure their communications. In such cases, the network facilities of the respective hosts may be used to secure the communications that they carry for the hosts. A common approach is to employ a security gateway such as the secure tunnel mode of the Internet Protocol (IP) Security protocol (IPSec), describe in RFC 7296 Section 1.1.1, which is commonly used to provide a site-to-site virtual private network (VPN). The IPSec gateway devices servicing the respective hosts' networks that provide this IPSec tunnel mode will be referred to herein as gateways.
- Providing IPSec tunnels is straightforward for a pair of subnets (virtual or logical) and respective directly communicating gateways. However, in modern network deployments, administrators may deploy many subnets on different clouds, each potentially providing communication with the others across the Internet. Each cloud may host multiple tenant subnets and assign its own pool of gateways to secure traffic to/from these subnets. However, due to the limited pool of available Internet addresses and other reasons, these gateways may have to share a limited number of Internet-routable IP addresses. Typically, these gateways are deployed behind some kind of network multiplexor, which multiplexes the traffic between the different gateways. That is, a multiplexor may help multiple gateways with private addresses share a small pool of Internet addresses.
- As observed only by the Inventors, this address-multiplexing approach gives rise to two fundamental problems. During IPsec tunnel establishment, the possibly-multiplexed IP addresses of the Internet Key Exchange (IKE) messages are used to choose the IKE policies that are used to negotiate the IKE Security Associations (SAs). However, as appreciated only by the inventors, since the IP addresses for IKE messages for different tunnel negotiations may be identical, there is ambiguity in choosing the correct policy and gateway to negotiate an SA. Put another way, IKE messages for two different tunnels may be indistinguishable based on their Internet addresses and therefore the tunnels have been unable to share the same Internet addresses.
- The second problem discovered by the inventors stems from the fact that the different IPsec tunnels connecting the various tenant subnets among the Internet-separated clouds are tightly coupled with a specific pair of gateways. All IPsec traffic—both control (IKE) and data (Encapsulating Security Payload (ESP)/Authentication Header AH)) exchanges must always be routed between the gateway devices associated with the tunnels; at each end, the same gateway must handle all of a given tunnel's traffic, even if they might otherwise be interchangeable with respect to routing. But when the gateways share multiplexed Internet addresses, the IPsec traffic for different tunnels would be indistinguishable from each other at the network layer, as the datagram IP addresses would be same for all such packets. As the Inventors have observed, this creates ambiguity in how the packets are routed to the appropriate Gateway devices and until now prevents address sharing.
- Techniques related to enabling IPSec tunnels over multiplexed Internet addresses are described below.
- The following summary is included only to introduce some concepts discussed in the Detailed Description below. This summary is not comprehensive and is not intended to delineate the scope of the claimed subject matter, which is set forth by the claims presented at the end.
- Embodiments relate to enabling clouds to multiplex their public network addresses among private addresses of IPSec gateways while making sure that IPSec tunnel packets are delivered to the private addresses of the IPSec tunnels that they are associated with. When IPSec packets egress from a cloud, the cloud may determine which IPSec tunnel or gateway the IPSec packets are associated with and modify the IPSec packets to identify the associated tunnel or gateway. When IPSec packets ingress to the cloud, the cloud may find identity information in the IPSec packets that identifies the associated tunnel or gateway (or security policy). The identity information is used to direct the IPSec packets to the associated tunnel or gateway.
- Many of the attendant features will be explained below with reference to the following detailed description considered in connection with the accompanying drawings.
- The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein like reference numerals are used to designate like parts in the accompanying description.
-
FIG. 1 shows a first pair of IPSec gateways. -
FIG. 2 shows a process by which a tunnel can be identified when its packets traverse a network using shared network addresses. -
FIG. 3 shows where tunnel identification can occur. -
FIG. 4 shows an embodiment for two different clouds that communicate via a common network. -
FIG. 5 shows how static port numbers of tunnel packets can be used to add identification to site-to-site tunnel related communications. -
FIG. 6 shows how a second packet completes the initiation shown inFIG. 5 . -
FIG. 7 shows details of a computing device on which embodiments described above may be implemented. -
FIG. 1 shows a first pair of IPSecgateways 100, 102 (GW-A1, GW-A2) communicating via anetwork 104 with a second pair of IPSecgateways 106, 108 (GW-B1, GW-B2). The first pair ofgateways first multiplexor 110.Multiplexor 110 may use network address translation (NAT) techniques to translate inbound traffic to the correct addresses of the gateways behind it and to translate outbound traffic to the shared address VIPA. Similarly, the second pair of gateways share another Internet-routable IP address—VIPB. VIPB is multiplexed by asecond multiplexor 112.Multiplexor 112 allows the second gateways to share VIPB by translating inbound traffic addressed to VIPB to the addresses of the second gateways and translating the addresses of the second gateways' outbound traffic to the shared address VIPB. - If the gateways implement the IPSec protocol to provide site-to-site tunnels, absent embodiments described herein, the following problems arise. Consider the
first multiplexor 110implementing process 114 for the IPSec protocol suite. Thefirst multiplexor 110 may receive from thesecond multiplexor 112 an IPSec datagram1 intended for afirst tunnel 116 associated with thefirst gateway 100. The first multiplexor also receives a second datagram2 from thesecond multiplexor 112 that is intended for asecond tunnel 118 associated with the otherfirst gateway 102. For datagram1, the first multiplexor must decide whether to pass it tofirst gateway 100 orfirst gateway 102. The same is true for datagram2: which gateway to address it to. However, as per the standard IPSec protocol and ordinary network translation, with respect to thefirst tunnel 116 andsecond tunnel 118, datagram1 and datagram2 are indistinguishable, from a network layer perspective. The multiplexor has no way to know which gateway should receive which datagram. - To clarify, the IPSec protocol specifies that the endpoints of a tunnel form an SA and the tunnel must flow through only those securely associated endpoints. The security association is, in effect, between the network addresses of the endpoints. A gateway will decide which datagrams belong to which tunnels based on “to” and “from” IP addresses of the datagrams. In the situation shown in
FIG. 1 , thefirst multiplexor 110 receives datagrams that have the same “to” and “from” addresses VIPA/VIPB. Thefirst multiplexor 110 has no way to determine which SA or gateway the inbound datagrams belong to. Thesecond multiplexor 112 has the same problem. The second multiplexor may have no way of determining which gateway datagram3 and datagram 4 should go to, or which tunnel or tenant they are associated with. -
FIG. 2 shows a process by which a tunnel can be identified when it traverses a network using shared network addresses (e.g., public IP addresses). Because standard SAs are one-way, it is preferable for the initiator of a communication exchange, whether for an IKE transmission or and ESP/HA transmission (referred to as IPSec communications/packets hereafter), to inject into its IPSec communication an identifier for the relevant tunnel that can be used on the receiving side to differentiate between tunnels. Note that such marking can be used to identify a particular gateway or tenant, as these three entities are somewhat equivalent. Description will refer to tunnels with the understanding that other entities may be identified. - Returning to
FIG. 2 , it will be assumed thatfirst gateway 100 is to initiate an IPSec communication, either for sending data or negotiating an SA. Asstep 130 thefirst gateway 100 receives a host or tenant packet to use or establish a site-to-site IPSec tunnel. Thefirst gateway 100 has a corresponding original tunnel packet that is publicly addressed to remote second multiplexor 112 (addressed to VIPB). The first gateway transmits the original tunnel packet to an internal interface of the first multiplexor. Atstep 132 the first multiplexor receives the original tunnel packet. The first gateway recognizes the tunnel packet and consequently proceeds to modify the tunnel packet to include indicia of the corresponding tunnel. Although the first multiplexor cannot directly control how the remote end responds, by including an identifier for the target tunnel, the sender enables the remote end to identify the target tunnel if it is appropriately configured etc. - At
step 134, after the marked tunnel packet addressed to thesecond multiplexor 112 is routed through the common network 104 (where VIPA and VIPB are routable), thesecond multiplexor 112 receives the tunnel packet. The second multiplexor reads the tunnel identifier and selects the corresponding gateway (how this can be done is described below). For example, if the packet is marked as being for a particular tunnel, tenant, or gateway, the multiplexor, in addition to performing functions necessary for address-multiplexing, may modify the tunnel packet to assure that it is delivered to the appropriate gateway and, in some embodiments, to allow the receiving gateway to determine which tunnel the packet is associated with. Atstep 136, themultiplexor 112. - The multiplexors may maintain or access
mapping information 138 which can be used to map the tunnel identifiers to the tunnel identifiers in the tunnel packets exchanged over thecommon network 104. Themapping information 138 may depend on how the tunnel identifiers are derived and/or are embedded in the tunnel packets. In some embodiments, mapping information is not needed and the opposing ends rely on conventions, static identifiers, combinations of header/packet information, etc. -
FIG. 3 shows where tunnel identification can occur. Although the modification of tunnel packets is described herein as occurring at address-multiplexing devices, as shown inFIG. 3 ,tunnel packet modification 148 may be performed at any point at or after a gateway (since an IPSec packet is formed at the gateway) and up to transmission to the common network. That is, packet marking or transformation can be done at any point before a packet leaves a cloud (for outbound packets) or at any point after a packet enters a cloud (for inbound packets). For example, a bump-in-the-line device or proxy server can be transparently employed, before or after the multiplexing device. Alternatively, the gateways may be provided with modules for modifying tunnel packets. Description of multiplexor tunneling functionality herein is applicable to any possible point of implementation. Moreover, the same flexibility of placing the tunneling functionality applies to the receiving/responding side. The responding side may recognize and act on a tunnel packet's tunnel identifier at any point between receipt from thecommon network 104 to delivery by a IPSec gateway. -
FIG. 4 shows an embodiment for two different clouds that communicate via thecommon network 104.Cloud A 150 may have one or more first IP addresses 152 that are shared amongfirst gateways FIG. 4 , the cloud A gateways share at least VIPA.First gateway 100 has an internal address DIPA1, andfirst gateway 102 has an internal address DIPA2. Similarly,cloud B 154 may multiplex one or more IP addresses 156, including at least VIPB, which is shared among thesecond gateways -
FIG. 5 shows how static port numbers of tunnel packets can be used to add identification to site-to-site tunnel related communications. The example ofFIG. 5 is for an IKE SA negotiation, although extension of the technique to other exchanges will be apparent. When cloud A determines that a first tunnel 116 (T1) is needed, thefirst gateway 100 sends afirst packet 170 to the first multiplexor 110 (or other point as mentioned above). Thefirst multiplexor 110 recognizes thefirst packet 170 as an IKE packet, the first multiplexor decides what identifier to use for the corresponding tunnel. In this example, the identifier is “X”, which could be any valid practical port number. The first multiplexor replaces the “from” port “500” in the first packet with “X” and changes the “from” address from DIPA1 to VIPA. The modifiedfirst packet 172 is then transmitted from an interface for VIPA. The modifiedfirst packet 172 is routed through thecommon network 104 to thesecond multiplexor 112. - The second multiplexor 112 (or another asset, as discussed above) receives the modified
second packet 172. The modifiedsecond packet 172 is analyzed and recognized as a tunnel packet (an IKE packet, in this example). Consequently, the tunnel identifier is extracted from the modifiedfirst packet 172. Although the port number is helpful for identifying a tunnel, the addresses of the modifiedfirst packet 172 may also help to identify the tunnel. Thesecond multiplexor 112 recognizes the identifier and, according thereto, determines which gateway in cloud B the modified first packet should be addressed to, namely, DIPB2 forsecond gateway 106. Thesecond multiplexor 112 maps the identifier (port X in this case) to the correct gateway instance. The packet is updated with the address of the correct gateway (second gateway 106). Thesecond multiplexor 112 then transmits the again-modified first packet from an internal interface to thesecond gateway 106. The second gateway is 106 is assured that it has received a packet for an SA attached/attaching to thesecond gateway 106. The use of “from” data to identify the tunnel enables the first packet to be properly routed through the common network but also carry additional information about the tunnel or gateway that can be used by cloud B. - The port number “X” in
FIG. 5 can be statically or dynamically determined by the sending side. In the static case, both ends know in advance which ports correspond to which tunnels, tenants, or gateways. The ports may be pre-configured in security policies, and when the SA is negotiated. Specifically, with the static port approach, when tunnel T1 is configured between VIPA and VIPB the port X is read from a policy and an associated NAT rule is configured to point to DIPB2 of GW-B2. In the dynamic port approach, a hash may be computed of the 3-tuple (source IP, source port, and destination IP), and the hash resolves to DIPB 2 of GW-B2. In either case, at cloud B, the incoming modified first packet is translated to be addressed to the correct gateway address—DIPB 2. On the second gateway the thus-transformed packet indicates the need for IKE service. By the RFC (Request For Comment) standard (see section 3.12 of RFC 7296), the IKE service is required to receive packets from any remote port and must send its response to the same remote port (X in this case), thus maintaining the port-tunnel association on both ends. - To elaborate on the dynamic port approach, the port reservation is dynamic in nature and is associated by the NAT (or equivalent component) to a particular gateway. Since multiple tunnels may terminate on the same gateway, such ports are not unique to a tunnel. But, it is unique to a gateway, across all gateways in a cloud deployment. The dynamic port approach implicitly assumes that every gateway device is configured with policies for all tunnels in that cloud deployment.
-
FIG. 6 shows how asecond packet 180 completes the initiation shown inFIG. 5 . The responder in thesecond gateway 106 uses NAT detection in the IKE message (per section 2.23 in RFC 7296) and determines that the first and second gateways are behind a NAT layer, and consequently switches to using UDP port “4500” for future IKE messages. Thesecond gateway 106 creates asecond packet 180, in this example, the response to the SA initialization packet from cloud A. The outboundsecond packet 180 is intercepted by thesecond multiplexor 112, which recognizes the source and port and translates thesecond packet 180 to a modifiedsecond packet 182 by changing: the “from” address from the second gateway's (DIPB2) to that of the multiplexed public address of cloud B (VIPB), the “from” port from “4500” to “X”, and the “to” port from “X” to “4500”. The modifiedsecond packet 182 is then transmitted over the common network from the interface for VIPB to the interface for VIPA. Cloud A then receives the modified second packet 182 (the IKE_SA_INIT response) in the same way that cloud B received the modified first packet, ultimately delivering the response to the correct gateway for the identified, tunnel, i.e., thefirst gateway 100. - Data packets (ESP packets) will also be encapsulated with UDP:4500. See RFC 7295, section 2.23 explaining why ESP packets would be UDP encapsulated. Data packets (UDP encapsulated ESP) will be transformed as follows, where “⇒” denotes a translation at a cloud, and where “{a:b, c:d}” denotes “from address a:port b, and to address c:port d”, and where the packets are marked as UDP encapsulated ESP packets.
- When a tunnel packet egresses from cloud A:
- Cloud A: {DIPA1:4500, VIPB:X}⇒{VIPA:X, VIPB:4500}.
- When the tunnel packet ingresses at cloud B:
- Cloud B: {VIPA:X, VIPB:4500}⇒{VIPA:X, DIPB2:4500}.
- When a tunnel packet egresses from cloud B:
- Cloud B: DIPB2:4500, VIPA:X}⇒{VIPB:X, VIPA:4500}.
- When the tunnel packet ingresses at cloud A:
- Cloud A: {VIPB:X, VIPA:4500}⇒{VIPB:X, DIPA1:4500}.
- If another IPSec tunnel is needed, say a
second tunnel T2 118, the second tunnel T2 may be handled as follows. Suppose that second gateway 106 (GW-B1) in cloud B initiates negotiation for thesecond tunnel T2 118. Suppose also that in this case it is port Y that is reserved for NAT-ing. Then all IKE and UDP encapsulated ESP packets fortunnel T2 118 will have source port Y. Further suppose that the other first gateway 102 (GW-A2) in Cloud A is selected for this port. Then all packets for tunnel T2 will flow between the other first gate 102 (GW-A2) and the second gateway 108 (GW-B1) without interfering with any traffic of tunnel T1. - As can be seen from
FIGS. 5 and 6 , regardless of the whether a static or dynamic approach is taken, IPSec exchanges involve a component at the transmitting side adding a tunnel identifier before an outbound tunnel packet is transmitted from a shared address routable on the common network. The receiving side can use the identifier to make sure that the tunnel packet goes to the gateway where the corresponding SA has been established. - Other embodiments, described next, may be used to negotiate multiple tunnels between a same pair of IP addresses.
- A tunnel identifier (ID) is to be used to identify each tunnel. The Tunnel ID uniquely identifies an IPsec tunnel across all tunnels configured in all gateways in the relevant clouds. The tunnel ID may be a globally unique identifier, a friendly string, or computed as a hash of various unique elements of the IKE policy. The tunnel ID should be known (or derivable independently) on the two gateways between which a given tunnel is to be established.
- Regarding the IKE_SA_INIT exchange, the two involved IKE peers negotiate the IKE SA. The initiator selects an IKE policy to use for the tunnel that is being established. With the static port approach, the NAT port is configured within the IKE policy. The IKE responder looks at the 3-tuple (Source IP, Source Port and Destination IP) of the incoming IKE message to find the matching IKE policy. With the dynamic port approach, the 3-tuple is not guaranteed to be unique to a tunnel in a Gateway. In this case, to pass the tunnel ID of the tunnel being established, the initiator sends a vendor ID payload (section 3.12 of RFC 7296) in the IKE_SA_INIT message.
- Regarding the IKE_SA_AUTH exchange, for the static port approach, as with the IKE_SA_INIT exchange, the 3-tuple (source IP, source port, destination IP) can be used to uniquely identify the IPsec policy. For the dynamic port approach, the tunnel ID can be passed to in the IDi (initiator ID) and optional IDr (responder ID) payload to identify the tunnel being established and to choose the appropriate IPsec policy to negotiate the child SA. The ID payloads are used in IKE_SA_AUTH exchange as follows (fields are described in the RFC):
- HDR, SK {IDi, [IDr, ]AUTH, SAi2, TSi, TSr} is sent, and
- HDR, SK {IDr, AUTH, SAr2, TSi, TSr} is sent in reply.
- Per section 3.5 of RFC 7296, the following identity-type is allowed to pass vendor-specific information: ID_KEY_ID. An opaque octet stream that may be used to pass vendor-specific information necessary to do certain proprietary types of identification. The initiator will use this for the IDi payloads. The responder will use this ID payload to find the right matching policy, which is used for child SA negotiation and to validate the AUTH payload (for shared secret-based authentication). CREATE_CHILD_SA exchanges are used to create new child SAs (of the SA established above) and to rekey both IKE SAs and child SAs. This will use the same pattern as IKE_SA_AUTH exchange.
-
FIG. 7 shows details of acomputing device 300 on which embodiments described above may be implemented. Thecomputing device 300 is an example of a client/personal device or backend physical (or virtual) server devices that may perform various (or perhaps most) of the processes described herein. The technical disclosures herein will suffice for programmers to write software, and/or configure reconfigurable processing hardware (e.g., field-programmable gate arrays (FPGAs)), and/or design application-specific integrated circuits (ASICs), etc., to run on the computing device 300 (possibly via cloud APIs) to implement the embodiments described herein. - The
computing device 300 may have one ormore displays 322, a camera (not shown), a network interface 324 (or several), as well asstorage hardware 326 andprocessing hardware 328, which may be a combination of any one or more: central processing units, graphics processing units, analog-to-digital converters, bus chips, FPGAs, ASICs, Application-specific Standard Products (ASSPs), or Complex Programmable Logic Devices (CPLDs), etc. Thestorage hardware 326 may be any combination of magnetic storage, static memory, volatile memory, non-volatile memory, optically or magnetically readable matter, etc. The meaning of the term “storage”, as used herein does not refer to signals or energy per se, but rather refers to physical apparatuses and states of matter. The hardware elements of thecomputing device 300 may cooperate in ways well understood in the art of machine computing. In addition, input devices may be integrated with or in communication with thecomputing device 300. Thecomputing device 300 may have any form-factor or may be used in any type of encompassing device. Thecomputing device 300 may be in the form of a handheld device such as a smartphone, a tablet computer, a gaming device, a server, a rack-mounted or backplaned computer-on-a-board, a system-on-a-chip, or others. - Embodiments and features discussed above can be realized in the form of information stored in volatile or non-volatile computer or device readable media. This is deemed to include at least media such as optical storage (e.g., compact-disk read-only memory (CD-ROM)), magnetic media, flash read-only memory (ROM), or any current or future means of storing digital information. The stored information can be in the form of machine executable instructions (e.g., compiled executable binary code), source code, bytecode, or any other information that can be used to enable or configure computing devices to perform the various embodiments discussed above. This is also deemed to include at least volatile memory such as random-access memory (RAM) and/or virtual memory storing information such as central processing unit (CPU) instructions during execution of a program carrying out an embodiment, as well as non-volatile media storing information that allows a program or executable to be loaded and executed. The embodiments and features can be performed on any type of computing device, including portable devices, workstations, servers, mobile wireless devices, and so on.
Claims (20)
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/937,831 US20190306116A1 (en) | 2018-03-27 | 2018-03-27 | Multiplexing security tunnels |
CN201980020114.3A CN111903105A (en) | 2018-03-27 | 2019-03-20 | Multiplex secure tunnel |
EP19715319.0A EP3753222A1 (en) | 2018-03-27 | 2019-03-20 | Multiplexing security tunnels |
PCT/US2019/023049 WO2019190829A1 (en) | 2018-03-27 | 2019-03-20 | Multiplexing security tunnels |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/937,831 US20190306116A1 (en) | 2018-03-27 | 2018-03-27 | Multiplexing security tunnels |
Publications (1)
Publication Number | Publication Date |
---|---|
US20190306116A1 true US20190306116A1 (en) | 2019-10-03 |
Family
ID=66001355
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/937,831 Abandoned US20190306116A1 (en) | 2018-03-27 | 2018-03-27 | Multiplexing security tunnels |
Country Status (4)
Country | Link |
---|---|
US (1) | US20190306116A1 (en) |
EP (1) | EP3753222A1 (en) |
CN (1) | CN111903105A (en) |
WO (1) | WO2019190829A1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11012473B1 (en) * | 2019-11-01 | 2021-05-18 | EMC IP Holding Company LLC | Security module for auto-generating secure channels |
US11368298B2 (en) * | 2019-05-16 | 2022-06-21 | Cisco Technology, Inc. | Decentralized internet protocol security key negotiation |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7478427B2 (en) * | 2003-05-05 | 2009-01-13 | Alcatel-Lucent Usa Inc. | Method and apparatus for providing adaptive VPN to enable different security levels in virtual private networks (VPNs) |
CN102055733B (en) * | 2009-10-30 | 2013-08-07 | 华为技术有限公司 | Method, device and system for negotiating business bearing tunnels |
US9204336B2 (en) * | 2010-08-17 | 2015-12-01 | Telefonaktiebolaget L M Ericsson (Publ) | Technique of processing network traffic that has been sent on a tunnel |
CN102833359A (en) * | 2011-06-14 | 2012-12-19 | 中兴通讯股份有限公司 | Tunnel information acquiring method, SeGW (security gateway), evolution H(e)NB (home node B)/H(e)NB |
US8943000B2 (en) * | 2012-01-20 | 2015-01-27 | Cisco Technology, Inc. | Connectivity system for multi-tenant access networks |
KR101686995B1 (en) * | 2015-07-08 | 2016-12-16 | 주식회사 케이티 | IPSec VPN Apparatus and system for using software defined network and network function virtualization and method thereof broadcasting |
-
2018
- 2018-03-27 US US15/937,831 patent/US20190306116A1/en not_active Abandoned
-
2019
- 2019-03-20 EP EP19715319.0A patent/EP3753222A1/en not_active Withdrawn
- 2019-03-20 CN CN201980020114.3A patent/CN111903105A/en active Pending
- 2019-03-20 WO PCT/US2019/023049 patent/WO2019190829A1/en unknown
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11368298B2 (en) * | 2019-05-16 | 2022-06-21 | Cisco Technology, Inc. | Decentralized internet protocol security key negotiation |
US11831767B2 (en) | 2019-05-16 | 2023-11-28 | Cisco Technology, Inc. | Decentralized internet protocol security key negotiation |
US11012473B1 (en) * | 2019-11-01 | 2021-05-18 | EMC IP Holding Company LLC | Security module for auto-generating secure channels |
Also Published As
Publication number | Publication date |
---|---|
WO2019190829A1 (en) | 2019-10-03 |
CN111903105A (en) | 2020-11-06 |
EP3753222A1 (en) | 2020-12-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9667594B2 (en) | Maintaining network address translations | |
US9172559B2 (en) | Method, apparatus, and network system for terminal to traverse private network to communicate with server in IMS core network | |
US7908651B2 (en) | Method of network communication | |
US9253146B2 (en) | Preventing duplicate sources from clients served by a network address port translator | |
CA2602778C (en) | Preventing duplicate sources from clients served by a network address port translator | |
US9654394B2 (en) | Multi-tenant system, switch, controller and packet transferring method | |
US8194683B2 (en) | Teredo connectivity between clients behind symmetric NATs | |
CN113259497A (en) | Method, device, storage medium and system for transmitting message | |
US20190306116A1 (en) | Multiplexing security tunnels | |
US20170207921A1 (en) | Access to a node | |
US7693091B2 (en) | Teredo connectivity between clients behind symmetric NATs | |
WO2014139646A1 (en) | Communication in a dynamic multipoint virtual private network | |
KR20230021506A (en) | Method for setting virtual network based on user-defined | |
US20190342263A1 (en) | Route reply back interface for cloud internal communication | |
CN117157959A (en) | Secure multi-cloud connectivity for cloud native applications |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SEAL, SHANKER;PAUL, ANIRBAN;BACHU, SAI KRISHNA GOUTHAM;AND OTHERS;SIGNING DATES FROM 20180328 TO 20180601;REEL/FRAME:045964/0862 |
|
AS | Assignment |
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE FIRST INVENTOR NAME PREVIOUSLY RECORDED AT REEL: 045964 FRAME: 0862. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT AND EXCLUSIVE RIGHTS, TITLE AND INTEREST;ASSIGNORS:SEAL, SHANKAR;PAUL, ANIRBAN;BACHU, SAI KRISHNA GOUTHAM;AND OTHERS;SIGNING DATES FROM 20180328 TO 20180601;REEL/FRAME:050032/0370 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |