WO2008095010A1 - Secure network switching infrastructure - Google Patents

Secure network switching infrastructure Download PDF

Info

Publication number
WO2008095010A1
WO2008095010A1 PCT/US2008/052475 US2008052475W WO2008095010A1 WO 2008095010 A1 WO2008095010 A1 WO 2008095010A1 US 2008052475 W US2008052475 W US 2008052475W WO 2008095010 A1 WO2008095010 A1 WO 2008095010A1
Authority
WO
WIPO (PCT)
Prior art keywords
flow
controller
switch
secure
switches
Prior art date
Application number
PCT/US2008/052475
Other languages
French (fr)
Inventor
Martin Casado
Nick Mckeown
Dan Boneh
Michael J. Freedman
Scott Shenker
Original Assignee
The Board Of Trustees Of The Leland Stanford Jr. University
International Computer Science Institute
The Regents Of The University Of California
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority to US88774407P priority Critical
Priority to US60/887,744 priority
Priority to US11/970,976 priority
Priority to US11/970,976 priority patent/US20080189769A1/en
Application filed by The Board Of Trustees Of The Leland Stanford Jr. University, International Computer Science Institute, The Regents Of The University Of California filed Critical The Board Of Trustees Of The Leland Stanford Jr. University
Publication of WO2008095010A1 publication Critical patent/WO2008095010A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to network resources
    • H04L63/102Entity profiles
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6281Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database at program execution time, where the protection is within the operating system
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/82Protecting input, output or interconnection devices
    • G06F21/85Protecting input, output or interconnection devices interconnection devices, e.g. bus-connected or in-line devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2129Authenticate client device independently of the user
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141Access rights, e.g. capability lists, access control lists, access tables, access matrices

Abstract

Use of a centralized control architecture in a network. Policy declaration, routing computation, and permission checks are managed by a logically centralized controller. By default, hosts on the network can only route to the network controller. Hosts and users must first authenticate themselves with the controller before they can request access to the network resources. The controller uses the first packet of each flow for connection setup. When a packet arrives at the controller, the controller decides whether the flow represented by that packet should be allowed. The switches use a simple flow table to forward packets under the direction of the controller. When a packet arrives that is not in the flow table, it is forwarded to the controller, along with information about which port the packet arrived on. When a packet arrives that is in the flow table, it is forwarded according to the controller's directive.

Description

SECURE NETWORK SWITCHING INFRASTRUCTURE

BACKGROUND OF THE INVENTION

1. Field of the Invention

[0001] The invention relates to network packet switching, and more particularly, to secure network packet switching.

2. Description of the Related Art

[0002] The Internet architecture was born in a far more innocent era, when there was little need to consider how to defend against malicious attacks. Many of the Internet's primary design goals that were so critical to its success, such as universal connectivity and decentralized control, are now at odds with security.

[0003] Worms, malware, and sophisticated attackers mean that security can no longer be ignored. This is particularly true for enterprise networks, where it is unacceptable to lose data, expose private information, or lose system availability. Security measures have been retrofitted to enterprise networks via many mechanisms, including router ACLs, firewalls, NATs, and middleboxes, along with complex link-layer technologies such as VLANs.

[0004] Despite years of experience and experimentation, these mechanisms remain far from ideal and have created a management nightmare. Requiring a significant amount of configuration and oversight, they are often limited in the range of policies that they can enforce and produce networks that are complex and brittle. Moreover, even with these techniques, security within the enterprise remains notoriously poor. Worms routinely cause significant losses in productivity and increase potential for data loss. Attacks resulting in theft of intellectual property and other sensitive information are also common.

[0005] Various shortcomings are present in the architecture most commonly used in today's networks. Today's networking technologies are largely based on Ethernet and IP, both of which use a destination based datagram model for forwarding. The source addresses of the packets traversing the network are largely ignored by the forwarding elements. This has two important, negative consequences. First, a host can easily forge its source address to evade filtering mechanisms in the network. Source forging is particularly dangerous within a LAN environment where it can be used to poison switch learning tables and ARP caches. Source forging can also be used to fake DNS and DHCP responses. Secondly, lack of in-network knowledge of traffic sources makes it difficult to attribute a packet to a user or to a machine. At its most benign, lack of attribution can make it difficult to track down the location of "phantom-hosts.'' More seriously, it may be impossible to determine the source of an intrusion gi\en a sufficiently clever attacker.

[0006] A typical enterprise network today uses several mechanisms simultaneously to protect its network: VLANs, ACLs, firewalls, NATs, and so on. The security policy is distributed among the boxes that implement these mechanisms, making it difficult to correctly implement an enterprise-wide security policy. Configuration is complex; for example, routing protocols often require thousands of lines of policy configuration. Furthermore, the configuration is often dependent on network topology and based on addresses and physical ports, rather than on authenticated end-points. When the topology changes or hosts move, the configuration frequently breaks, requires careful repair , and potentially undermines its security policies.

[0007] A common response is to put all security policy in one box and at a choke-point in the network, for example, in a firewall at the network's entry and exit points. If an attacker makes it through the firewall, then they will have unfettered access to the whole network. Further, firewalls have been largely restricted to enforcing coarse-grain network perimeters. Even in this limited role, misconfiguration has been a persistent problem . This can be attributed to several factors; in particular, their low-level policy specification and highly localized view leaves firewalls highly sensitive to changes in topology.

[0008] Another way to address this complexity is to enforce protection of the end host via distributed firewalls. While reasonable, this places all trust in the end hosts. For this end hosts to perform enforcement, the end host must be trusted (or at least some part of it, e.g., the OS, a VMM, the NIC, or some small peripheral). End host firewalls can be disabled or bypassed, leaving the network unprotected, and they offer no containment of malicious infrastructure, e.g., a compromised NIDS. Furthermore, in a distributed firewall scenario, the network infrastructure itself receives no protection, i.e., the network still allows connectivity by default. This design affords no defense-in-depth if the end-point firewall is bypassed, as it leaves all other network elements exposed.

[0009] Today's networks provide a fertile environment for the skilled attacker, switches and routers must correctly export link state, calculate routes, and perform filtering; over time, these mechanisms have become more complex, with new vulnerabilities discovered at an alarming rate. If compromised, an attacker can take down the network or redirect traffic to permit eavesdropping, traffic analysis, and man-in-the-middle attacks.

[0010] Another resource for an attacker is the proliferation of information on the network layout of today's enterprises. This knowledge is valuable for identifying sensitive servers, firewalls, and IDS systems that can be exploited for compromise or denial of service. Topology information is easy to gather: switches and routers keep track of the network topology (e.g., the OSPF topology database) and broadcast it periodically in plain text. Likewise, host enumeration (e.g., ping and ARP scans), port scanning, traceroutes, and SNMP can easily reveal the existence of, and the route to, hosts. Today, it is common for network operators to filter ICMP and disable or change default SNMP passphrases to limit the amount of information available to an intruder. As these services become more difficult to access, however, the network becomes more difficult to diagnose.

[0011] Today's networks trust multiple components, such as firewalls, switches, routers, DNS, and authentication services (e.g., Kerberos, AD, and Radius). The compromise of any one component can wreak havoc on the entire enterprise. [0012] Weaver et al. argue that existing configurations of coarse-grain network perimeters (e.g., NIDS and multiple firewalls) and end host protective mechanisms (e.g. antivirus software) are ineffective against worms when employed individually or in combination. They advocate augmenting traditional coarse-grain perimeters with fine-grain protection mechanisms throughout the network, especially to detect and halt worm propagation.

[0013] There are a number of Identity-Based Networking (IBN) solutions available in the industry. However, most lack control of the datapath, are passive, or require modifications to the end-hosts.

[0014] VLANs are widely used in enterprise networks for segmentation, isolation, and enforcement of course-grain policies; they are commonly used to quarantine unauthenticated hosts or hosts without health certificates. VLANs are notoriously difficult to use, requiring much hand-holding and manual configuration.

[0015] Often misconfigured routers make firewalls simply irrelevant by routing around them. The inability to answer simple reachability questions in today's enterprise networks has fueled commercial offerings to help administrators discover what connectivity exists in their network.

[0016] In their 4D architecture, Rexford et al., "NetworkWide Decision

Making: Toward A Wafer- Thin Control Plane," Proc. Hotnets, Nov. 2004, argue that the decentralized routing policy, access control, and management has resulted in complex routers and cumbersome, difficult- to -manage networks. They argue that routing (the control plane) should be separated from forwarding, resulting in a very simple data path. Although 4D centralizes routing policy decisions, they retain the security model of today's networks. Routing (forwarding tables) and access controls (filtering rules) are still decoupled, disseminated to forwarding elements, and operate the basis of weakly-bound end-point identifiers (IP addresses). [0017] Predicate routing attempts to unify security and routing by defining connectivity as a set of declarative statements from which routing tables and filters are generated. In contrast, our goal is to make users first-class objects, as opposed to end-point IDs or IP addresses, that can be used to define access controls.

[0018] In addition to retaining the characteristics that have resulted in the wide deployment of IP and Ethernet networks - simple use model, suitable (e.g.. Gigabit) performance, the ability to scale to support large organizations, and robustness and adaptability to failure - a solution should address the deficiencies addressed here.

SUMMARY OF THE INVENTION

[0019] In order to achieve the properties described in the previous section, embodiments according to our invention utilize a centralized control architecture, fhe preferred architecture is managed from a logically centralized controller. Rather than distributing policy declaration, routing computation, and permission checks among the switches and routers, these functions are all managed by the controller. As a result, the switches arc reduced to very simple, forwarding elements whose sole purpose is to enforce the controller's decisions.

[0020] Centralizing the control functions provides the following benefits.

First, it reduces the trusted computing base by minimizing the number of heavily trusted components on the network to one, in contrast to the prior designs in which a compromise of any of the trusted services, LDAP, DNS, DHCP, or routers can wreak havoc on a network. Secondly, limiting the consistency protocols between highly trusted entities protects them from attack. Prior consistency protocols are often done in plaintext (e.g. dyndns) and can thus be subverted by a malicious party with access to the traffic. Finally, centralization reduces the overhead required to maintain consistency.

[0021] In the preferred embodiments the network is "off-by-default." That is, by default, hosts on the network cannot communicate with each other; they can only route to the network controller. Hosts and users must first authenticate themselves with the controller before they can request access to the network resources and, ultimately, to other end hosts. Allowing the controller to interpose on each communication allows strict control over all network flows. In addition, requiring authentication of all network principals (hosts and users) allows control to be defined over high level names in a secure manner.

[0022] The controller uses the first packet of each flow for connection setup.

When a packet arrives at the controller, the controller decides whether the flow represented by that packet should be allowed. The controller knows the global network topology and performs route computation for permitted flows. It grants access by explicitly enabling flows within the network switches along the chosen route. The controller can be replicated for redundancy and performance.

[0023] In the preferred embodiments the switches are simple and dumb.

The switches preferably consist of a simple How table which forwards packets under the direction of the controller. When a packet arrives that is not in the flow table, they forward that packet to the controller, along with information about which port the packet arrived on. When a packet arrives that is in the flow table, it is forwarded according to the controller's directive. Not every switch in the network needs to be one of these switches as the design allows switches to be added gradually: the network becomes more manageable with each additional switch.

[0024] When the controller checks a packet against the global policy, it is preferably evaluating the packet against a set of simple rules, such as "Guests can communicate using HTTP, but only via a web proxy"' or "VoIP phones are not allowed to communicate with laptops." To aid in allowing this global policy to be specified in terms of such physical entities, there is a need to reliably and securely associate a packet with the user, group, or machine that sent it. If the mappings between machine names and IP addresses (DNS) or between IP addresses and MAC addresses (ARP and DHCP) are handled elsewhere and are unreliable, then it is not possible to tell who sent the packet, even if the user authenticates with the network. With logical centralization it is simple to keep the namespace consistent, as components join, leave and move around the network. Network state changes simply require updating the bindings at the controller.

[0025] In the preferred embodiments a scries of sequences of techniques are used to secure the bindings between packet headers and the physical entities that sent them. First, the controller takes over all the binding of addresses. When machines use DHCP to request an IP address, the controller assigns it knowing to which switch port the machine is connected, enabling the controller to attribute an arriving packet to a physical port. Second, the packet must come from a machine that is registered on the network, thus attributing it to a particular machine. Finally, users are required to authenticate themselves with the network, for example, via FFfTP redirects in a manner similar to those used by commercial WiFi hotspots, binding users to hosts. Therefore, whenever a packet arrives to the controller, it can securely associate the packet to the particular user and host that sent it.

[0026J There are several powerful consequences of the controller knowing both where users and machines are attached and all bindings associated with them. The controller can keep track of where any entity is located. When it moves, the controller finds out as soon as packets start to arrive from a different switch port or wireless access point. The controller can choose to allow the new flow (it can even handle address mobility directly in the controller without modifying the host) or it might choose to deny the moved flow (e.g., to restrict mobility for a VoIP phone due to E911 regulations). Another powerful consequence is that the controller can journal all bindings and flow-entries in a log. Later, if needed, the controller can reconstruct all network events; e.g., which machines tried to communicate or which user communicated with a service. This can make it possible to diagnose a network fault or to perform auditing or forensics, long after the bindings have changed.

[0027] Therefore networks according to the present invention address problems with prior art network architectures, improving overall network security. BRIEF DESCRIPTION OF THE FIGURES

[0028] Figure 1 is a block diagram of a network according to the present invention.

[0029] Figure 2 is a block diagram of the logical components of the controller of Figure 1.

[0030] Figure 3 is a block diagram of switch hardware and software according to the present invention.

[0031] Figure 4 is a block diagram of the data path of the switch of Figure 3.

[0032] Figure 5 is a block diagram of software modules of the switch of

Figure 3.

[0033] Figures 6 and 7 arc block diagrams of networks incorporating prior art switches and switches according to the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0034] Referring now to Figure 1, a network 100 according to the present invention is illustrated. A controller 102 is present to provide network control functions as described below. A series of interconnected switches 104A-D are present to provide the basic packet switching function. A wireless access point 106 is shown connected to switch 104A to provide wireless connectivity. For the following discussion, in many aspects the access point 106 operates as a switch 104. Servers 108 A-D and workstations 11 OA-D are connected to the switches 104A-D. A notebook computer 1 12 having wireless network capabilities connects to the access point 106. The servers 108, workstations 110 and notebook 112 are conventional units and are not modified to operate on the network 100. This is a simple network for purposes of illustration. An enterprise network will have vastly more components but will function on the same principles. [0035] With reference to Figure 1, there are five basic activities that define how the network 100 operates. A first activity is registration. All switches 104, users, servers 108, workstations 110 and notebooks 112 are registered at the controller 102 with the credentials necessary to authenticate them. The credentials depend on the authentication mechanisms in use. For example, hosts, collectively the servers 108, workstations 1 10 and notebooks 112, may be authenticated by their MAC addresses, users via usernamc and password, and switches through secure certificates. All switches 104 are also preconfigured with the credentials needed to authenticate the controller 102 (e.g., the controller's public key).

[0036] A second activity is bootstrapping. Switches 104 bootstrap connectivity by creating a spanning tree rooted at the controller 102. As the spanning tree is being created, each switch 104 authenticates with and creates a secure channel to the controller 102. Once a secure connection is established, the switches 104 send link-state information to the controller 102 which is then aggregated to reconstruct the network topology. Each switch 104 knows only a portion of the network topology. Only the controller 102 is aware of the full topology, thus improving security.

[0037] A third activity is authentication. Assume User A joins the network with host HOC. Because no flow entries exist in switch 104D for the new host, it will initially forward all of the host HOC packets to the controller 102 (marked with the switch 104D ingress port, the default operation for any unknown packet). Next assume Host HOC sends a DIICP request to the controller 102. After checking the host HOC MAC address, the controller 102 allocates an IP address (IP HOC) for it, binding host 1 1OC to IP 1 K)C, IP 1 1OC to MAC HOC, and MAC HOC to a physical port on switch 104D. In the next operation User A opens a web browser, whose traffic is directed to the controller 102, and authenticates through a web-form. Once authenticated, user A is bound to host 102.

[0038] A fourth activity is flow setup. To begin, User A initiates a connection to User B at host HOD, who is assumed to have already authenticated in a manner similar to User A. Switch 104D forwards the packet to the controller 102 after determining that the packet does not match any active entries in its flow table. On receipt of the packet, the controller 102 decides whether to allow or deny the flow, or require it to traverse a set of waypoints. If the flow is allowed, the controller 102 computes the flow's route, including any policy-specified waypoints on the path. The controller 102 adds a new entry to the flow tables of all the switches 104 along the path.

[0039] The fifth aspect is forwarding. If the controller 102 allowed the path, it sends the packet back to switch 104D which forwards it to the switch 104C based on the new flow entry. Switch 104C in turn forwards the packet to switch 104B, which in turn forwards the packet to host HOD based on its new flow entry. Subsequent packets from the flow are forwarded directly by the switch 104D, and are not sent to the controller 102. The flow-entry is kept in the relevant switches 104 until it times out or is revoked by the controller 102.

[0040] Λ switch 104 is like a simplified Ethernet switch. It has several

Ethernet interfaces that send and receive standard Ethernet packets. Internally, however, the switch 104 is much simpler, as there are several things that conventional Ethernet switches do that the switch 104 need not do. The switch 104 does not need to learn addresses, support VLANs, check for source-address spoofing, or keep flow-level statistics (e.g., start and end time of flows, although it will typically maintain per (low packet and byte counters for each flow entry). If the switch 104 is replacing a layer-3 "'switch" or router, it does not need to maintain forwarding tables, ACLs, or NAT. It does not need to run routing protocols such as OSPF, ISIS, and RIP. Nor does it need separate support for SPANs and port-replication. Port-replication is handled directly by the flow table under the direction of the controller 102.

[00411 It is also worth noting that the flow table can be several orders-of- magnitude smaller than the forwarding table in an equivalent Ethernet switch. In an Ethernet switch, the table is sized to minimize broadcast traffic: as switches flood during learning, this can swamp links and makes the network less secure. As a result, an Ethernet switch needs to remember all the addresses it's likely to encounter; even small wiring closet switches typically contain a million entries. The present switches 104, on the other hand, can have much smaller flow tables: they only need to keep track of flows in-progress. For a wiring closet, this is likely to be a few hundred entries at a time, small enough to be held in a tiny fraction of a switching chip. Even for a campus-level switch, where perhaps tens of thousands of flows could be ongoing, it can still use on-chip memory that saves cost and power.

[0042] The switch 104 datapath is a managed flow table. Flow entries contain a Header (to match packets against), an Action (to tell the switch 104 what to do with the packet), and Per-Flow Data described below. There are two common types of entries in the flow table: per-flow entries describing application flows that should be forwarded, and pcr-host entries that describe misbehaving hosts whose packets should be dropped. For TCP/UDP flows, the Header field covers the TCP/UDP, IP, and Ethernet headers, as well as physical port information. The associated Action is to forward the packet to a particular interface, update a packet-and-byte counter in the Per-Flow Data, and set an activity bit so that inactive entries can be timed-out. For misbehaving hosts, the Header field contains an Ethernet source address and the physical ingress port. The associated Action is to drop the packet, update a packet-and-byte counter, and set an activity bit to tell when the host has stopped sending.

[0043] Only the controller 102 can add entries to the flow table of the switch

104. Entries are removed because they timeout due to inactivity, which is a local decision, or because they are revoked by the controller 102. The controller 102 might revoke a single, badly behaved flow, or it might remove a whole group of flows belonging to a misbehaving host, a host that has just left the network, or a host whose privileges have just changed.

[0044] The flow table is preferably implemented using two exact-match tables: One for application flow entries and one for misbehaving host entries. Because flow entries arc exact matches, rather than longest-prefix matches, it is easy to use hashing schemes in conventional memories rather than expensive, power-hungry TCAMs.

[0045J Other actions are possible in addition to just forward and drop. For example, a switch 104 might maintain multiple queues for different classes of traffic, and the controller 102 can tell it to queue packets from application flows in a particular queue by inserting queue IDs into the flow table. This can be used for end-to-end layer-2 isolation for classes of users or hosts. A switch 104 could also perform address translation by replacing packet headers. This could be used to obfuscate addresses in the network 100 by ''swapping" addresses at each switch 104 along the path, so that an eavesdropper would not be able to tell which end- hosts are communicating, or to implement address translation for NAT in order to conserve addresses. Finally, a switch 104 could control the rate of a flow.

[0046] The switch 104 also preferably maintains a handful of implementation-specific entries to reduce the amount of traffic sent to the controller 102. For example, the switch 104 can set up symmetric entries for flows that are allowed to be outgoing only. This number should remain small to keep the switch 104 simple, although this is at the discretion of the designer. On one hand, such entries can reduce the amount of traffic sent to the controller 102; on the other hand, any traffic that misses on the flow table will be sent to the controller 102 anyway, so this is just an optimization.

[0047] It is worth pointing out that the secure channel from a switch 104 to its controller 102 may pass through other switches 104. As far as the other switches 104 are concerned, the channel simply appears as an additional flow- entry in their table.

[0048] The switch 104 needs a small local manager to establish and maintain the secure channel to the controller 102, to monitor link status, and to provide an interface for any additional switch-specific management and diagnostics. This can be implemented in the switch's software layer. [0049] There are two ways a switch 104 can talk to the controller 102. The first one, which has been discussed so far, is for switches 104 that are part of the same physical network as the controller 102. This is expected to be the most common case; e.g., in an enterprise network on a single campus. In this case, the switch 104 finds the controller 102, preferably using the modified Minimum Spanning Tree protocol described below. The process results in a secure channel from switch 104 to switch 104 all the way to the controller 102. If the switch 104 is not within the same broadcast domain as the controller 102, the switch 104 can create an IP tunnel to it after being manually configured with its IP address. This approach can be used to control switches 104 in arbitrary locations, e.g., the other side of a conventional router or in a remote location. In one interesting application, the switch 104, most likely a wireless access point 106, is placed in a home or small business, managed remotely by the controller 102 over this secure tunnel. The local switch manager relays link status to the controller 102 so it can reconstruct the topology for route computation.

[0050] Switches 104 maintain a list of neighboring switches 104 by broadcasting and receiving neighbor-discovery messages. Neighbor lists are sent to the controller 102 after authentication, on any detectable change in link status, and periodically every 15 seconds.

[0051] Figure 2 gives a logical block-diagram of the controller 102. The components do not have to be co-located on the same machine and can operate on any suitable hardware and software environment, the hardware including a CPU, memory for storing data and software programs, and a network interface and the software including an operating system, a network interface driver and various other components described below.

[0052] Briefly, the components work as follows. An authentication component 202 is passed all traffic from unauthenticated or unbound MAC addresses. It authenticates users and hosts using credentials stored in a registration database 204 and optionally provides IP addresses when serving as the DHCP server. Once a host or user authenticates, the controller 102 remembers to which switch port they are connected. The controller 102 holds the policy rules, stored in a policy file 206, which are compiled by a policy compiler 208 into a fast lookup table (not shown). When a new flow starts, it is checked against the rules by a permission check module 210 to see if it should be accepted, denied, or routed through a waypoint. Next, a route computation module 212 uses the network topology 214 to pick the flow's route which is used in conjunction with the permission information from the permission check module 210 to build the various flow table entries provided to the switches 104. The topology 214 is maintained by a switch manager 216, which receives link updates from the switches 104 as described above.

[0053] All entities that are to be named by the network 100 (i.e., hosts, protocols, switches, users, and access points) must be registered. The set of registered entities make up the policy namespace and is used to statically check the policy to ensure it is declared over valid principles. The entities can be registered directly with the controller 102, or — as is more likely in practice, the controller 102 can interface with a global registry such as LDAP or AD, which would then be queried by the controller 102. By forgoing switch registration, it is also possible to provide the same '"plug-and-play 102" configuration model for switches as Ethernet. Under this configuration the switches 104 would distribute keys on boot-up, rather than requiring manual distribution, under the assumption that the network 100 has not yet been compromised.

[0054] All switches, hosts, and users must authenticate with the network

100. No particular host authentication mechanism is specified; a network 100 could support multiple authentication methods (e.g., 802. Ix or explicit user login) and employ entity-specific authentication methods. In a preferred embodiment hosts authenticate by presenting registered MAC addresses, while users authenticate through a web front-end to a Kerberos server. Switches 104 authenticate using SSL with server- and client-side certificates.

[0055] One of the powerful features of the present network 100 is that it can easily track all the bindings between names, addresses, and physical ports on the network 100, even as switches 104, hosts, and users join, leave, and move around the network 100. It is this ability to track these dynamic bindings that makes a policy language possible. It allows description of policies in terms of users and hosts, yet implementation of the policy uses flow tables in switches 104.

[0056J A binding is never made without requiring authentication, to prevent an attacker assuming the identity of another host or user. When the controller 102 detects that a user or host leaves, all of its bindings are invalidated, and all of its flows are revoked at the switch 104 to which it was connected. Unfortunately, in some cases, we cannot get reliable explicit join and leave events from the network 100. Therefore, the controller 102 may resort to timeouts or the detection of movement to another physical access point before revoking access.

[0057] Because the controller 102 tracks all the bindings between users, hosts, and addresses, it can make information available to network managers, auditors, or anyone else who seeks to understand who sent what packet and when. In current networks, while it is possible to collect packet traces, it is almost impossible to figure out later which user, or even which host, sent or received the packets, as the addresses are dynamic and there is no known relationship between users and packet addresses.

[00S8] The controller 102 can journal all the authentication and binding information: The machine a user is logged in to, the switch port their machine is connected to, the MAC address of their packets, and so on. Armed with a packet trace and such a journal, it is possible to determine exactly which user sent a packet, when it was sent, the path it took, and its destination. Obviously, this information is very valuable for both fault diagnosis and identifying break-ins. On the other hand, the information is sensitive and controls need to be placed on who can access it. Therefore the controllers 102 should provide an interface that gives privileged users access to the information. In one preferred embodiment, we built a modified DNS server that accepts a query with a timestamp, and returns the complete bound namespace associated with a specified user, host, or IP address. [0059] The controller 102 can be implemented to be stateful or stateless. A stateful controller 102 keeps track of all the flows it has created. When the policy changes, when the topology changes, or when a host or user misbehaves, a stateful controller 102 can traverse its list of flows and make changes where necessary. A stateless controller 102 does not keep track of the flows it created; it relies on the switches 104 to keep track of their flow tables. If anything changes or moves, the associated flows would be revoked by the controller 102 sending commands to the switch's Local Manager. It as a design choice whether a controller 102 is stateful or stateless, as there are arguments for and against both approaches.

[0060] There are many occasions when a controller 102 wants to limit the resources granted to a user, host, or flow. For example, it might wish to limit a flow's rate, limit the rate at which new flows are setup, or limit the number of IP addresses allocated. The limits will depend on the design of the controller 102 and the switch 104, and they will be at the discretion of the network manager. In general, however, the present invention makes it easy to enforce these limits either by installing a filter in a switch's flow table or by telling the switch 104 to limit a flow's rate.

[0061] The ability to directly manage resources from the controller 102 is the primary means of protecting the network from resource exhaustion attacks. To protect itself from connection flooding from unauthenticated hosts, a controller 102 can place a limit on the number of authentication requests per host and per switch port; hosts that exceed their allocation can be closed down by adding an entry in the flow table that blocks their Ethernet address. If such hosts spoof their address, the controller 102 can disable the switch port. A similar approach can be used to prevent flooding from authenticated hosts.

[0062] Flow state exhaustion attacks are also preventable through resource limits. Since each flow setup request is attributable to a user, host or access point, the controller 102 can enforce limits on the number of outstanding flows per identifiable source. The network 100 may also support more advanced flow allocation policies, such as enforcing strict limits on the number of flows forwarded in hardware per source, and looser limits on the number of flows in the slower (and more abundant) software forwarding tables.

[0063] Enterprise networks typically carry a lot of multicast and broadcast traffic. Indeed, VLANs were first introduced to limit overwhelming amounts of broadcast traffic. It is worth distinguishing broadcast traffic which is mostly discovery protocols, such as ΛRP from multicast traffic which is often from useful applications, such as video. In a flow-based network as in the present invention, it is quite easy for switches 104 to handle multicast. The switch 104 keeps a bitmap for each flow to indicate which ports the packets arc to be sent to along the path.

[0064] In principle, broadcast discovery protocols are also easy to handle in the controller 102. Typically, a host is trying to find a server or an address. Given that the controller 102 knows all, it can reply to a request without creating a new flow and broadcasting the traffic. This provides an easy solution for ARP traffic, which is a significant fraction of all network traffic. The controller 102 knows all IP and Ethernet addresses and can reply directly. In practice, however, ARP could generate a huge load for the controller 102. One embodiment would be to provide a dedicated ARP server in the network 100 to which that all switches 104 direct all ARP traffic. But there is a dilemma when trying to support other discovery protocols; each one has its own protocol, and it would be onerous for the controller 102 to understand all of them. The preferred approach has been to implement the common ones directly in the controller 102, and then broadcast low-level requests with a rate-limit. While this approach does not scale well, this is considered a legacy problem and discovery protocols will largely go away when networks according to the present invention are adopted, being replaced by a direct way to query the network, sue as one similar to the fabric login used in Fibre Channel networks.

[0065] Designing a network architecture around a central controller 102 raises concerns about availability and scalability. While measurements discussed below suggest that thousands of machines can be managed by a single desktop computer, multiple controllers 102 may be desirable to provide fault-tolerance or to scale to very large networks. This section describes three techniques for replicating the controller 102. In the simplest two approaches, which focus solely on improving fault-tolerance, secondary controllers 102 are ready to step in upon the primary's failure. These can be in cold-standby, having no network binding state, or warm-standby, having network binding state, modes. In the fully- replicated model, which also improves scalability, requests from switches 104 are spread over multiple active controllers 102.

[0066] In the cold-standby approach, a primary controller 102 is the root of the modified spanning tree (MST) and handles all registration, authentication, and flow establishment requests. Backup controllers sit idly-by waiting to take over if needed. All controllers 102 participate in the MST, sending HELLO messages to switches 104 advertising their ID. Just as with a standard spanning tree, if the root with the "lowest" ID fails, the network 100 will converge on a new root, i.e., a new controller. If a backup becomes the new MST root, they will start to receive flow requests and begin acting as the primary controller. In this way, controllers 102 can be largely unaware of each other. The backups need only contain the registration state and the network policy. As this data changes very slowly, simple consistency methods can be used. The main advantage of cold-standby is its simplicity. The downside is that hosts, switches, and users need to rc- authenticatc and re-bind upon primary failure. Furthermore, in large networks, it might take a while for the MST to reconverge.

[0067] The warm-standby approach is more complex, but recovers faster. In this approach, a separate MST is created for every controller. The controllers monitor one another's liveness and, upon detecting the primary's failure, a secondary controller takes over based on a static ordering. As before, slowly- changing registration and network policy arc kept consistent among the controllers, but now binds must be replicated across controllers as well. Because these bindings can change quickly as new users and hosts come and go, it is preferred that only weak consistency be maintained. Because controllers make bind events atomic, primary failures can at worst lose the latest bindings, requiring that some new users and hosts rc-authenticate themselves.

[0068] The fully-replicated approach takes this one step further and has two or more active controllers. While an MST is again constructed for each controller, a switch need only authenticate itself to one controller and can then spread its flow-requests over the controllers (e.g., by hashing or round-robin). With such replication, the job of maintaining consistent journals of the bind events is more difficult. It is preferred that most implementations will simply use gossiping to provide a weakly-consistent ordering over events. Pragmatic techniques can avoid many potential problems that would otherwise arise, e.g., having controllers use different private IP address spaces during DHCP allocation to prevent temporary IP allocation conflicts. Of course, there are well-known, albeit heavier- weight, alternatives to provide stronger consistency guarantees if desired (e.g., replicated state machines).

[0069] Link and switch failures must not bring down the network 100 as well. Recall that switches 104 always send neighbor-discovery messages to keep track of link-state. When a link fails, the switch 104 removes all flow table entries tied to the failed port and sends its new link-state information to the controller 102. This way, the controller 102 also learns the new topology. When packets arrive for a removed flow-entry at the switch 104, the packets are sent to the controller 102, much like they are new flows, and the controller 102 computes and installs a new path based on the new topology.

[0070] When the network 100 starts, the switches 104 must connect and authenticate with the controller 102. On startup, the network creates a minimum spanning tree with the controller 102 advertising itself as the root. Each switch 104 has been configured with credentials for the controller 102 and the controller 102 with the credentials for all the switches 104. If a switch 104 finds a shorter path to the controller 102, it attempts two way authentication with it before advertising that path as a valid route. Therefore the minimum spanning tree grows radially from the controller 102, hop-by-hop as each switch 104 authenticates. [0071] Authentication is done using the preconfigured credentials to ensure that a misbehaving node cannot masquerade as the controller 102 or another switch 104. If authentication is successful, the switch 104 creates an encrypted connection with the controller 102 which is used for all communication between the pair.

[0072] By design, the controller 102 knows the upstream switch 104 and physical port to which each authenticating switch 104 is attached. After a switch 104 authenticates and establishes a secure channel to the controller 102, it forwards all packets it receives for which it does not have a flow entry to the controller 102, annotated with the ingress port. This includes the traffic of authenticating switches 104. Therefore the controller 102 can pinpoint the attachment point to the spanning tree of all non-authenticated switches 104 and hosts. Once a switch 104 authenticates, the controller 102 will establish a flow in the network between itself and a switch 104 for the secure channel.

[0073] Pol-Eth is a language according to the present invention for declaring policy in the network 100. While a particular language is not required, Pol-Eth is described as an example.

[0074] In Pol-Eth, network policy is declared as a set of rules, each consisting of a condition and a corresponding action. For example, the rule to specify that user bob is allowed to communicate with the HTTP server (using HTTP) is:

[0075] [(usrc="bob")Λ(protocol="http")Λ(hdst='Veb-scrver")]:allow;

[0076] Conditions are a conjunction of zero or more predicates which specify the properties a flow must have in order for the action to be applied. From the preceding example rule, if the user initiating the flow is "bob" and the flow protocol is "HTTP" and the flow destination is host "http-server", then the flow is allowed. The left hand side of a predicate specifies the domain, and the right hand side gives the entities to which it applies. For example, the predicate (usrc="bob") applies to all flows in which the source is user bob. Valid domains include {usrc, udst, lisrc, hdst, apsrc, apdst, protocol}, which respectively signify the user, host, and access point sources and destinations and the protocol of the flow.

[0077] In Pol-Eth, the values of predicates may include single names (e.g.,

"bob"), lists of names (e.g., [''bob'Y'linda*']), or group inclusion (e.g., in("workstations")). All names must be registered with the controller 102 or declared as groups in the policy file, as described below.

[0078] Actions include allow, deny, waypoints, and outbound-only (for

NAT-like security). Waypoint declarations include a list of entities to route the flow through, e.g., waypoints ("ids","http-proxy").

10079] Pol-Eth rules are independent and do not contain an intrinsic ordering. Thus, multiple rules with conflicting actions may be satisfied by the same flow. Conflicts are preferably resolved by assigning priorities based on declaration order, though other resolution techniques may be used. If one rule precedes another in the policy file, it is assigned a higher priority.

[0080] As an example, in the following declaration, bob may accept incoming connections even if he is a student.

[0081] # bob is unrestricted [(udst=" bob")]: allow;

[0082] # all students can make outbound connections

[(usrc=in(' " students"))] : outbound-only;

[0083] # deny everything by default) [] : deny ;

[0084] Unfortunately, in today's multi-user operating systems, it is difficult from a network perspective to attribute outgoing traffic to a particular user. According to the present invention, if multiple-users are logged into the same machine (and not identifiable from within the network), the network applies the least restrictive action to each of the flows. This is an obvious relaxation of the security policy. To address this, it is possible to integrate with trusted end-host operating systems to provide user-isolation and identification, for example, by providing each user with a virtual machine having a unique MAC.

[0085] Pol-Eth also allows predicates to contain arbitrary functions. For example, the predicate (cxpr="foo'") will execute the function "'foo'* at runtime and use the boolean return value as the outcome. Predicate functions are written in C++ and executed within the network namespace. During execution, they have access to all parameters of the flow as well as to the full binding state of the network.

[0086] The inclusion of arbitrary functions with the expressibility of a general programming language allows predicates to maintain local state, affect system state, or access system libraries. For example, we have created predicates that depend on the time-of- day and contain dependencies on which users or hosts are logged onto the network. A notable downside is that it becomes impossible to statically reason about safety and execution times: a poorly written function can crash the controller or slow down permission checks.

[0087] Given how frequently new flows are created - and how fast decisions must be made - it is not practical to interpret the network policy. Instead, it is preferred to compile it. But compiling Pol-Eth is non-trivial because of the potentially huge namespace in the network. Creating a lookup table for all possible flows specified in the policy would be impractical.

[0088] A preferred Pol-Eth implementation combines compilation and just- in-timc creation of search functions. Each rule is associated with the principles to which it applies. This is a one-time cost, performed at startup and on each policy change.

[0089] The first time a sender communicates to a new receiver, a custom permission check function is created dynamically to handle all subsequent flows between the same source/destination pair. The function is generated from the set of rules which apply to the connection. In the worst case, the cost of generating the function scales linearly with the number of rules (assuming each rule applies to every source entity). If all of the rules contain conditions that can be checked statically at bind time (i.e., the predicates are defined only over users, hosts, and access points), then the resulting function consists solely of an action. Otherwise, each flow request requires that the actions be aggregated in real-time.

[0090] We have implemented a source-to-sourcc compiler that generates

C++ from a Pol-Eth policy file. The resulting source is then compiled and linked into a binary. As a consequence, policy changes currently require re-linking the controller. We are currently upgrading the policy compiler so that policy changes can be dynamically loaded at runtime.

[0091] A functional embodiment of a network according to the present invention has been built and deployed. In that embodiment the network 100 connected over 300 registered hosts and several hundred users. The embodiment included 19 switches of three different types: wireless access points 106, and Ethernet switches in two types dedicated hardware and software. Registered hosts included laptops, printers, VoIP phones, desktop workstations and servers.

[0092] Three different switches have been tested. The first is an 802.1 Ig wireless access point based on a commercial access point. The second is a wired 4-port Gigabit Ethernet switch that forwards packets at line-speed based on the NetFPGA programmable switch platform, and written in Verilog. The third is a wired 4-port Ethernet switch in Linux on a desktop-PC in software, as a development environment and to allow rapid deployment and evolution.

[0093] For design re-use, the same flow table was implemented in each switch design even though it is preferable to optimize for each platform. The main table for packets that should be forwarded has 8k flow entries and is searched using an exact match on the whole header. Two hash functions (two CRCs) were used to reduce the chance of collisions, and only one flowr was placed in each entry of the table. 8k entries were chosen because of the limitations of the programmable hardware (NetFPGA). A commercial ASIC-based hardware switch, an NPU-based switch, or a software-only switch would support many more entries. A second table wras implemented to hold dropped packets which also used exact-match hashing. In that implementation, the dropped table was much bigger (32k entries) because the controller was stateless and the outbound- only actions were implemented in the flow table. When an outbound flow starts, it is preferable to setup the return-route at the same time. Because the controller is stateless, it does not remember that the outbound-flow was allowed. Unfortunately, wiicn proxy ARP is used, the Ethernet address of packets flowing in the reverse direction were not known until they arrive. The second table was used to hold flow entries for return-routes, with a wildcard Ethernet address, as well as for dropped packets. A stateful controller would not need these entries. Finally, a third small table for flows with wildcards in any field was used. These are there for convenience during prototyping, to aid in determining how many entries a real deployment would need. It holds How entries for the spanning tree messages, ARP and DHCP.

[0094] The access point ran on a Linksys WRTSL54GS wireless router running Open WRT. The data-path and flow table were based on 5K lines of C++, of which 1.5K were for the flow table. The local switch manager is written in software and talks to the controller using the native Linux TCP stack. When running from within the kernel, the forwarding path runs at 23Mb/s, the same speed as Linux IP forwarding and layer 2 bridging.

[0095] The hardware switch was implemented on NetFPGA v2.0 with four

Gigabit Ethernet ports, a Xilinx Virtex-Il FPGA and 4Mbytes of SRAM for packet buffers and the flow table. The hardware forwarding path consisted of 7k lines of Vcrilog; flow-entries were 40 bytes long. The hardware can forward minimum size packets in full-duplex at line -rate of lGb/s.

[0096] To simplify definition of a switch, a software switch was built from a regular desktop-PC and a 4-port Gigabit Ethernet card. The forwarding path and the flow table was implemented to mirror the hardware implementation. The software switches in kernel mode can forward MTU size packets at 1 Gb/s. However, as the packet size drops, the CPU cannot keep up. At 100 bytes, the switch can only achieve a throughput of 16Mb/s. Clearly, for now, the switch needs to be implemented in hardware.

[0097] The preferred switch design as shown in Figure 3 is decomposed into two memory independent processes, the datapath and the control path. A CPU or processor 302 forms the primary compute and control functions of the switch 300. Switch memory 304 holds the operating system 306, such as Linux; control path software 308 and datapath software 310. A switch ASIC 312 is used in the preferred embodiment to provide hardware acceleration to readily enable line rate operation. If the primary datapath operators arc performed by the datapath software 310, the ASIC 312 is replaced by a simple network interface. The control path software 308 manages the spanning tree algorithm, and handles all communication with the controller and performs other local manager functions. The datapath software 310 performs the forwarding.

[0098] The control path software 308 preferably runs exclusively in user- space and communicates to the datapath software 310 over a special interface exported by the datapath software 310. The datapath software 310 may run in user-space or within the kernel. When running with the hardware switch ASIC 312, the datapath software 310 handles setting the hardware flow entries, secondary and tertiary flow lookups, statistics tracking, and timing out flow entries, switch control and management software 314 is also present to perform those functions described in more detail below.

[0099] Figure 4 shows a decomposition of the functional software and hardware layers making up the switch datapath. In Block 402 received packets are checked for a valid length and undersized packets are dropped. In preparation for calculating the hash-functions, Block 404 parses the packet header to extract the following fields: Ethernet header, IP header, and TCP or UDP header. fOOlOO] A flow-tuple is built for each received packet; for an IPv4 packet, the tuple has 155 bits consisting of: MAC DA (lower 16 bits), MAC SA (lower 16 bits), Ethertypc (16 bits), IP src address (32 bits), IP dst address (32 bits), IP protocol field (8 bits), TCP or UDP src port number (16 bits), TCP or UDP dst port number (16 bits), received physical port number (3 bits).

[00101] Block 406 computes two hash functions on the flow-tuple (padded to 160 bits), and returns two indices. Block 408 uses the indices to lookup into two hash tables in SRAM. The flow table stores 8,192 flow entries. Each flow entry holds the 155 bit flow tuple (to confirm a hit or a miss on the hash table), and a 152 bit field used to store parameters for an action when there is a lookup hit. The action fields include one bit to indicate a valid flow entry, three bits to identify a destination port (physical output port, port to CPU, or null port that drops the packet), 48 bit overwrite MAC DA, 48 bit overwrite MAC SA, a 20-bit packet counter, and a 32 bit byte counter. The 307-bit flow-entry is stored across two banks of SRAM 410 and 412.

[00102] Block 414 controls the SRAM, arbitrating access for two requestors: The flow table lookup (two accesses per packet, plus statistics counter updates), and the CPU 302 via a PCI bus. Every 16 system clock cycles, the block 414 can read two flow-tuples, update a statistics counter entry, and perform one CPU access to write or read 4 bytes of data. To prevent counters from overflowing, in the illustrated embodiment the byte counters need to be read every 30 seconds by the CPU 302, and the packet counters every 0.5 seconds. Alternatives can increase the size of the counter field to reduce the load on the CPU or use well- known counter-caching techniques.

[00103] Block 416 buffers packets while the header is processed in Blocks 402 - 408, 414. If there was a hit on the flow table, the packet is forwarded accordingly to the correct outgoing port, the CPU port, or could be actively dropped. If there was a miss on the flow table, the packet is forwarded to the CPU 302. Block 418 can also overwrite a packet header if the flow table so indicates. Packets are provided from block 418 to one of three queues 420, 422, 424. Queues 420 and 422 are connected to a mux 426 to provide packets to the Ethernet MAC FIFO 428. Two queues are used to allow prioritization of flows if desired, such as new flows to the controller 102. Queue 424 provides packets to the CPU 302 for operations not handled by the hardware. A fourth queue 430 receives packets from the CPU 302 and provides them to the mux 426, allowing CPU-generated packets to be directly transmitted.

[00104] Overall, the hardware is controlled by the CPU 302 via memory- mapped registers over the PCI bus. Packets are transferred using standard DMA.

[00105] Figure 5 contains a high-level view of the switch control path. The control path manages all communications with the controller such as forwarding packets that have failed local lookups, relaying flow setup, tear-down, and filtration requests.

[00106] The control path uses the local TCP stack 502 for communication to the controller using the datapath 400. By design, the datapath 400 also controls forwarding for the local protocol stack. This ensures that no local traffic leaks onto the network that was not explicitly authorized by the controller 102.

[00107] All per-packet functions that do not have per-packet time constraints are implemented within the control path. This ensures that the datapath will be simple, fast and amenable to hardware design and implementation. The implementation includes a DHCP client 504, a spanning tree protocol stack 506, a SSL stack 508 for authentication and encryption of all data to the controller, and support 510 for flow setup and flow-learning to support outbound-initiated only traffic.

[00108] The switch control and management software 314 has two responsibilities. First, it establishes and maintains a secure channel to the controller 102. On startup, all the switches 104 find a path to the controller 102 by building a modified spanning-tree. with the controller 102 as root. The control software 314 then creates an encrypted TCP connection to the controller 102. This connection is used to pass link-state information (which is aggregated to form the network topology) and all packets requiring permission checks to the controller 102. Second, the software 314 maintains a flow table for flow entries not processed in hardware, such as overflow entries due to collisions in the hardware hash table, and entries with wildcard fields. Wildcards are used for the small implementation-specific table. The software 314 also manages the addition, deletion, and timing-out of entries in the hardware.

[00109] If a packet does not match a flow entry in the hardware flow table, it is passed to software 314. The packet did not match the hardware flow table because: (i) It is the first packet of a flow and the controller 102 has not yet granted it access (ii) It is from a revoked flow or one that was not granted access (iii) It is part of a permitted flow but the entry collided with existing entries and must be managed in software or (iv) It matches a flow entry containing a wildcard field and is handled in software.

[00110] In the full software design of the switch two flow tables were maintained, one as a secondary hash table for implementation-specific entries and the second as an optimization to reduce traffic to the controller. For example, the second table can be set up symmetric entries for flows that are allowed to be outgoing only. Because you cannot predict the return source MAC address when proxy ARP is used, traffic to the controller is saved by maintaining entries with wildcards for the source MAC address and incoming port. The first flow table is a small associative memory to hold flow-entries that could not find an open slot in either of the two hash tables. Tn a dedicated hardware solution, this small associative memory would be placed in hardware. Alternatively, a hardware design could use a TCAM for the whole flow table in hardware.

[00111] The controller was implemented on a standard Linux PC (1.6GHz Intel Celeron processor and 512MB of DRAM). The controller is based on 45K lines of C++, with an additional 4K lines generated by the policy compiler, and 4.5K lines of python for the management interface. [00112] Switches and hosts were registered using a web-interface to the controller and the registry was maintained in a standard database. For access points, the method of authentication was determined during registration. Users were registered using a standard directory service.

[00113] In the implemented system, users authenticated using the existing system, which used Kerberos and a registry of usernames and passwords. Users authenticate via a web interface. When they first connect to a browser they are redirected to a login web-page. In principle, any authentication scheme could be used, and most enterprises would have their own. Access points also, optionally, authenticate hosts based on their Ethernet address, which is registered with the controller.

[00114] The implemented controller logged bindings whenever they were added, removed or on checkpointing the current bind-state. Each entry in the log was timestamped.

[00115] The log was easily queried to determine the bind-state at any time in the past. The DNS server was enhanced to support queries of the form key.domain.type-time, where "type" can be "host", "'user"', "MAC", or "port". The optional time parameter allows historical queries, defaulting to the present time.

[00116] Routes were pre-computcd using an all pairs shortest path algorithm. Topology recalculation on link failure was handled by dynamically updating the computation with the modified link-state updates. Even on large topologies, the cost of updating the routes on failure was minimal. For example, the average cost of an update on a 3,000 node topology was 10ms.

[00117] The implementation was deployed in an existing 100Mb/s Ethernet network. Included in the deployment were eleven wired and eight wireless switches according to the present invention. There were approximately 300 hosts on the network, with an average of 120 hosts active in a 5 -minute window. A network policy was created to closely match, and in most cases exceed, the connectivity control already in place. The existing policy was determined by looking at the use of VLANs. end-host firewall configurations. NATs and router ACLs. omitting rules no longer relevant to the current state of the network.

[00118] Briefly, within the policy, non-servers (workstations, laptops, and phones) were protected from outbound connections from servers, while workstations could communicate uninhibited. Hosts that connected to a switch port registered an Ethernet address, but required no user authentication. Wireless nodes protected by WPA and a password did not require user authentication, but if the host MAC address was not registered they can only access a small number of services (HTTP, HTTPS, DNS, SMTP, IMAP, POP, and SSH). Open wireless access points required users to authenticate through the existing system. The VoIP phones were restricted from communicating with non-phones and were statically bound to a single access point to prevent mobility (for R91 1 location compliance). The policy file was 132 lines long.

[00119] By deploying this embodiment, measurements of performance were made to understand how the network can scale with more users, end-hosts and switches. In the deployed 300 host network, there were 30-40 new flow-requests per second with a peak of 750 flow7-requests per second. Under load the controller flows were set up in less than 1.5ms in the worst case, and the CPU showed negligible load for up to 11,000 flows per second, which is larger than the actual peak detected. This number would increase with design optimization.

[00120] With this in mind, it is worth asking to how many end-hosts this load corresponds. Two recent datasets were considered, one from an 8,000 host network and one from a 22.000 host network at a university. The number of maximum outstanding flows in the traces from the first network never exceeded 1,500 per second for 8.000 hosts. The university dataset had a maximum of under 9,000 new flow-requests per second for 22,000 hosts. [00121J This indicates that a single controller could comfortably manage a network with over 20,000 hosts. Of course, in practice, the rule set would be larger and the number of physical entities greater; but on the other hand, the ease with which the controller handled this number of flows suggests there is room for improvement.

[00122J Next the size of the flow table in the switch was evaluated. Ideally, the switch can hold all of the currently active flows. In the deployed implementation it never exceeded 500. With a table of 8,192 entries and a two- function hash-table, there was never a collision.

[00123] In practice, the number of ongoing flows depends on where the switch is in the network. Switches closer to the edge will see a number of flows proportional to the number of hosts they connect to — and hence their fanout. The implemented switches had a fanout of four and saw no more than 500 flows. Therefore a switch with a fanout of, say, 64 would see at most a few thousand active flows. A switch at the center of a network will likely see more active flows, presumably all active flows. From these numbers it is concluded that a switch for a university-sized network should have a flow table capable of holding 8- 16k entries. If it is assumed that each entry is 64B, it suggests the table requires about 1MB; or as large as 4MB if using a two-way hashing scheme. A typical commercial enterprise Ethernet switch today holds 1 million Ethernet addresses (6MB, but larger if hashing is used), 1 million IP addresses (4MB of TCAM), 1-2 million counters (8MB of fast SRAM), and several thousand ACLs (more TCAM). Therefore the memory requirements of the present switch are quite modest in comparison to current Ethernet switches.

[00124] To further explore the scalability of the controller, its performance was tested with simulated inputs in software to identify overheads. The controller was configured with a policy file of 50 rules and 100 registered principles. Routes were pre-calculated and cached. Under these conditions, the system could handle 650,845 bind events per second and 16,972,600 permission checks per second. The complexity of the bind events and permission checks is dependent on the rules in use and in the worst case grows linearly with the number of rules.

[00125] Because the implemented controller used cold-standby failure recovery, a controller failure would lead to interruption of service for active flows and a delay while they were re-established. To understand how long it took to reinstall the flows, the completion time of 275 consecutive HTTP requests, retrieving 63MBs in total was measured. While the requests were ongoing, the controller was crashed and restarted multiple times. There was clearly a penalty for each failure, corresponding to a roughly 10% increase in overall completion time. This could be largely eliminated, of course, in a network that uses warm- standby or fully-replicated controllers to more quickly recover from failure.

[00126] Link failures require that all outstanding flows re-contact the controller in order to re-establish the path. If the link is heavily used, the controller will receive a storm of requests, and its performance will degrade. A topology with redundant paths was implemented, and the latencies experienced by packets were measured. Failures were simulated by physically unplugging a link. In all cases, the path re-convcrged in under 40ms; but a packet could be delayed by up to a second while the controller handled the flurry of requests.

[00127] The network policy allowed for multiple disjoint paths to be setup by the controller when the flow was created. This way, convergence could occur much faster during failure, particularly if the switches detected a failure and failed over to using the backup flow-entry.

[00128] Figures 6 and 7 illustrate inclusion of prior art switches in a network according to the present invention. This illustrates that a network according to the present invention can readily be added to an existing network, thus allowing additional security to be added incrementally instead of requiring total replacement of the infrastructure. [00129] In Figure 6, a prior art switch 602 is added connecting to switches 104B, 104C and 104D, with switches 104B and 104D no longer being directly connected to switch 104C. Figure 7 places a second prior art switch 702 between switch 602 and switch 104D and has new workstations HOE and HOF connected directly to it.

[00130] Operation of the mixed networks 600 and 700 differs from that of network 100 in the following manners. In the network 600, full network control can be maintained even though a prior art switch 602 is included in the network 600. Any flows to or from workstations 11OA, HOB and HOC, other than those between those workstations, must pass through switch 602. Assuming a flow from workstation 110Λ, after passing through switch 602 the packet will either reach switch 104B or switch 104C. Both switches will know the incoming port which receives packets from switch 602. Thus a flow from workstation HOC to server 108D would have flow table entries in switches 104D and 104C. The entry in switch 104D would be as in network 100, with the TCP/UDP, IP and Ethernet headers and the physical receive port to which the workstation 1 1OC is connected. T he flow table would include an action entry of the physical port to which switch 602 is connected so that the flow is properly routed. The entry in switch 104C would include the TCP/UDP, IP and Ethernet headers and the physical receive port to which the switch 602 is connected. Thus if switch 104C receives a similarly addressed packet but at another port, it knows it should forward the packet to the controller 102. Therefore, because the controller 102 will learn the routing table of the switch 602 during the initial flow set ups, it will be able to properly set up flows in all o the switches 110 in the network to maintain full security.

[00131] The network 700 operates slightly differently due to the interconnected nature of switches 602 and 702 and to the workstations HOE and 1 1OF being connected to switch 702. Communications between workstations HOE and 11 OF can be secured only using prior art techniques in switch 702. Any other communications will be secure as they must pass through switches 104. [00132] Thus it can be seen that a fully secure network can be developed if all of the switches forming the edge of the network are switches according to the present invention, even if all of the core switches are prior art switches. In that case the controller 102 will flood the network to find the various edge switches 104. As the switches 104 will not be configured, they will return the packet to the controller 102, thus indicating their presence and locations.

[00133] Appreciable security can also be developed in a mixed network which uses core switches according to the present invention and prior art switches at the edge. As in network 700, there would be limited security between hosts connected to the same edge switch but flows traversing the network would be secure.

[00134] A third mixed alternative is to connect all servers to switches according to the present invention, with any other switches of less concern. This arrangement would secure communications with the servers, often the most critical. One advantage of this alternative is that fewer switches might be required as there are usually far fewer servers than workstations. Overall security would improve as any prior art switches are replaced with switches according to the present invention.

[00135] Thus switches according to the present invention, and the controller, can be incorporated into existing networks in several ways, with the security level varying dependent on the deployment technique, but not requiring a complete infrastructure replacement.

[00136] This description describes a new approach to dealing with the security and management problems found in today's enterprise networks. Ethernet and IP networks are not well suited to address these demands. Their shortcomings are many fold. First, they do not provide a usable namespace because the name to address bindings and address to principle bindings are loose and insecure. Secondly, policy declaration is normally over low-level identifiers (e.g., IP addresses, VLANs, physical ports and MAC addresses) that don't have clear mappings to network principles and are topology dependant. Encoding topology in policy results in brittle networks whose semantics change with the movement of components. Finally, policy today is declared in many files over multiple components. This requires the human operator to perform the labor intensive and error prone process of manual consistency.

[00137] Networks according to the present invention address these issues by offering a new architecture for enterprise networks. First, the network control functions, including authentication, name bindings, and routing, are centralized. This allows the network to provide a strongly bound and authenticated namespace without the complex consistency management required in a distributed architecture. Further, centralization simplifies network-wide support for logging, auditing and diagnostics. Second, policy declaration is centralized and over high- level names. This both decouples the network topology and the network policy, and simplifies declaration. Finally, the policy is able to control the route a path takes. This allows the administrator to selectively require traffic to traverse middleboxes without having to engineer choke points into the physical network topology.

[00138] While the invention has been particularly shown and described with respect to preferred embodiments thereof, it will be understood by those skilled in the art that changes in form and details may be made therein without departing from the scope and spirit of the invention.

Claims

1. A method for operating a packet switching network, the network including a plurality of switches interconnected to allow packets received at a switch to be provided to each switch, at least one of the plurality of switches being a secure switch, the network further including a controller connected to at least one of the plurality of switches and able to receive packets from the secure switch, a plurality of hosts connected to selected of the plurality of switches, the secure switch including a flow table with entries indicating allowable flows between hosts and directions for forwarding allowable flows, the method comprising the steps of: the secure switch developing a secure connection with the controller; the controller authenticating a host connected to the secure switch; the host initiating a (low to another host; the secure switch interrogating a flow table upon receiving a flow from a host, determining if the flow is contained in the flow table, forwarding at least the first packet of the flow to the controller if the flow is not contained in the flow table and forwarding the packets as directed by the flow table if the flow is contained in the flow table; and the controller receiving the at least first packet of a flow not contained in the flow table of the secure switch, determining that the flow is allowed, setting up a flow table entry in the secure switch upon determining that the flow is allowed and returning the packet to the secure switch for further flow table interrogation after setting up the flow table entry in the secure switch.
2. The method of claim 1 further comprising the steps of: the controller receiving an authentication request from a user of the host; and the controller authenticating the user and thereafter including user information in the determination if a flow is allowed.
3. The method of claim 1. wherein a plurality of secure switches are included in the network and each perform the steps of developing secure connections with the controller, interrogating a flow table; forwarding to the controller if not contained in the flow table and forwarding as directed if contained in the flow table, and wherein the controller sets up flow table entries in each secure switch if the secure switch is in the flow path between the hosts of the flow.
4. The method of claim 1, further comprising the step of: the secure switch creating a spanning tree rooted at the controller.
5. A packet switching network for connecting a plurality of hosts, the nctwOrk comprising: a plurality of switches for connection to the plurality of hosts, said plurality of switches interconnected to allow packets received at a switch to be provided to each switch, said plurality of switches including a secure switch which includes a flow table with entries indicating allowable flows between hosts and directions for forwarding allowable flows; and a controller, said controller connected to said secure switch, wherein said secure switch and said controller interact to developing a secure connection between themselves, wherein said controller authenticates a host when connected to said secure switch. wherein said secure switch interrogates said How table upon receiving a flow from a host, determines if said flow is contained in said flow table, forwards at least the first packet of said flow to said controller if said flow is not contained in said flow table and forwards the packets as directed by said flow table if said flow is contained in said flow table; and wherein said controller receives said at least first packet of said flow not contained in said flow table of said secure switch, determines that said flow is allowed, sets up a flow table entry in said secure switch upon determining that said How is allowed and returns said at least first packet to said secure switch for further flow table interrogation after setting up said flow table entry in said secure switch.
6. The network of claim 5 wherein said controller authenticates a user of the host providing said flow to said secure switch; and wherein after authenticating the user, said controller thereafter includes user information in the determination if a flow is allowed.
7. The network of claim 5, wherein said secure switch creates a spanning tree rooted at said controller.
8. T he network of claim 5, wherein said plurality of switches include a plurality of secure switches, each including flow tables, wherein each of said secure switches and said controller interact to develop secure connections, wherein each of said secure switches interrogate their said flow table; forward at least the first packet of said flow to said controller if said flow is not contained in said flow table and forward the packets as directed by said flow table if said flow is contained in said flow table, and wherein said controller sets up flow table entries in each of said secure switches if the secure switch is in the flow path between the hosts of said flow.
9. The network of claim 8, wherein said secure switches are all of said plurality of switches.
10. The network of claim 5, wherein at least one switch of said plurality of switches is not a secure switch, and wherein said at least one switch which is not a secure switch is interconnected with the remainder of said plurality of switches so that at least some flows between the hosts pass through said at least one switch which is not a secure switch.
11. A controller for use in a packet switching network connecting a plurality of hosts, the network including a plurality of switches for connection to the plurality of hosts, the plurality of switches interconnected to allow packets received at a switch to be provided to each switch, the plurality of switches including a secure switch which includes a How table with entries indicating allowable flows between hosts and directions for forwarding allowable flows, the controller comprising: a network interface for interconnection to at least one of said plurality of switches; a CPU coupled to said network interface; and memory coupled to said CPU and storing data and software programs executed on said CPU, said software programs including: an operating system; a component to interact with the secure switch to develop a secure connection between said controller and the secure switch; a component to authenticate a host when connected to the secure switch; and a component to receive at least a first packet of a flow between two hosts not contained in the flow table of the secure switch, to determine that said flow is allowed, to set up a flow table entry in the flow table in the secure switch upon determining that said flow is allowed and to return said at least first packet to the secure switch after setting up said flow table entry in the secure switch.
12. The controller of claim 1 1 , wherein said software programs further include: a component to authenticate a user of the host providing said flow to the at least one switch, and wherein after authenticating the user, said component which determines if a flow is allowed thereafter including user information in the determination if a flow is allowed.
13. The controller of claim 11, wherein at least two switches of the plurality of switches are secure switches and include flow tables, wherein said component to interact with the at least one switch to develops a secure connection each of the secure switches, wherein said component to authenticate a host authenticates hosts connected to each of the plurality of the secure switches, wherein said component to receive at least a first packet, to determine that said flow is allowed, to set up a flow table entry in the flow table and to return said at least first packet does so for each of the plurality of the secure switches and further sets up flow table entries in each of the plurality of the secure switches if the secure switch is in the flow path between the hosts of the flow.
14. The controller of claim 11, wherein said software programs further include: a component to maintain the topology of the network, said topology component cooperating with said component to set up flow table entries.
15. The controller of claim 1 1, wherein said software programs further include: a component to maintain network policies, said policy component cooperating with said component determined if the flow is allowed.
16. The controller of claim 1 1, wherein said component to authenticate a host when connected to the secure switch further provides an IP address to the host.
17. A secure switch for use in a packet switching network for connecting a plurality of hosts, the network including a controller and a plurality of switches, the plurality of switches interconnected to allow packets received at a switch to be provided to each switch and to the controller, the secure switch comprising: a network interface for interconnection to at least one of said plurality of switches and to which a host may be connected; memory containing a flow table, said flow table including entries indicating allowable flows between hosts and directions for forwarding allowable flows; logic coupled to said network interface to interact with the controller to develop a secure connection between the controller and the secure switch; logic coupled to said network interface to receive a flow from a host and interrogate said flow table upon receiving said flow, determine if said flow is contained in said flow table, forward at least the first packet of said flow to the controller if said flow is not contained in said flow table and forward the packets as directed by said flow table if said flow is contained in said flow table; logic coupled to said network interface to receive flow table entries from the controller and place them in said flow table; and logic coupled to said network interlace to receive a packet returned from the controller and provide it to the logic to interrogate said flow table.
18. The secure switch of claim 17, further comprising: logic coupled to said network interface to create a spanning tree rooted at the controller.
19. The secure switch of claim 17, further comprising: a CPU coupled to said network interface; and memory coupled to said CPU and storing data and software programs executed on said CPU, said software programs including: an operating system; a component to handle control operations of the secure switch; and a component to handle data operations of the secure switch, wherein said component to handle control operations forms at least a portion of said logic to develop a secure connection between the controller and the secure switch, and wherein one of said component to handle control operations and said component to handle data operations forms at least a portion of said logic coupled to said network interface to receive How table entries from the controller and place them in said flow table.
20. The secure switch of claim 17, wherein directions for forwarding allowable flows in said flow table include forwarding the packet to an indicated port, altering a header in the packet and place the packet in a designated queue.
21. The secure switch of claim 17, wherein said flow table entries include packet header information and incoming port number to allow comparison with a received packet.
PCT/US2008/052475 2007-02-01 2008-01-30 Secure network switching infrastructure WO2008095010A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US88774407P true 2007-02-01 2007-02-01
US60/887,744 2007-02-01
US11/970,976 2008-01-08
US11/970,976 US20080189769A1 (en) 2007-02-01 2008-01-08 Secure network switching infrastructure

Publications (1)

Publication Number Publication Date
WO2008095010A1 true WO2008095010A1 (en) 2008-08-07

Family

ID=39674487

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2008/052475 WO2008095010A1 (en) 2007-02-01 2008-01-30 Secure network switching infrastructure

Country Status (2)

Country Link
US (1) US20080189769A1 (en)
WO (1) WO2008095010A1 (en)

Cited By (144)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012050071A1 (en) 2010-10-14 2012-04-19 日本電気株式会社 Communication system, control device, method for setting processing rules, and program
WO2012070173A1 (en) 2010-11-22 2012-05-31 Nec Corporation Communication system, communication device, controller, and method and program for controlling forwarding path of packet flow
WO2012081146A1 (en) 2010-12-16 2012-06-21 Nec Corporation Communication system, control apparatus, communication method, and program
WO2012081145A1 (en) 2010-12-13 2012-06-21 Nec Corporation Communication path control system, path control device, communication path control method, and path control program
WO2012081721A1 (en) 2010-12-17 2012-06-21 日本電気株式会社 Communication system, node, packet transfer method and program
WO2012090996A1 (en) 2010-12-28 2012-07-05 日本電気株式会社 Information system, control device, virtual network provision method and program
WO2012090355A1 (en) 2010-12-28 2012-07-05 Nec Corporation Communication system, forwarding node, received packet process method, and program
WO2012098596A1 (en) 2011-01-20 2012-07-26 Nec Corporation Communication system, control device, policy management device, communication method, and program
WO2012101689A1 (en) 2011-01-28 2012-08-02 Nec Corporation Communication system, forwarding node, control device, communication control method, and program
WO2012144203A1 (en) 2011-04-18 2012-10-26 Nec Corporation Terminal, control device, communication method, communication system, communication module,program, and information processing device
WO2012144190A1 (en) 2011-04-18 2012-10-26 Nec Corporation Terminal, control device, communication method,communication system, communication module, program, and information processing device
WO2012144583A1 (en) 2011-04-21 2012-10-26 日本電気株式会社 Communication system, control device, communication method, and program
CN102783098A (en) * 2010-03-05 2012-11-14 日本电气株式会社 Communication system, path control apparatus, packet forwarding apparatus and path control method
WO2012169164A1 (en) 2011-06-06 2012-12-13 Nec Corporation Communication system, control device, and processing rule setting method and program
US20130003745A1 (en) * 2010-03-24 2013-01-03 Kouichi Nishimura Information system, control device, method of managing virtual network, and program
WO2013022082A1 (en) 2011-08-11 2013-02-14 日本電気株式会社 Packet forwarding system, control device, packet forwarding method and program
WO2013031175A1 (en) 2011-08-29 2013-03-07 Nec Corporation Communication system, control device, node, node control method, and program
WO2013031233A1 (en) 2011-09-01 2013-03-07 Nec Corporation Communication terminal, communication method, communication system, and program
JP2013048364A (en) * 2011-08-29 2013-03-07 Nec Corp Communication system, control device, packet transfer method, and program
WO2013042358A1 (en) 2011-09-21 2013-03-28 Nec Corporation Communication apparatus, communication system, communication control method, and program
WO2013042374A1 (en) 2011-09-21 2013-03-28 Nec Corporation Communication apparatus, control apparatus, communication system, communication control method, and program
WO2013042346A1 (en) 2011-09-21 2013-03-28 Nec Corporation Communication apparatus, communication system, communication control method, and computer program
WO2013062070A1 (en) 2011-10-28 2013-05-02 日本電気株式会社 Control apparatus, communication system, virtual network management method, and program
WO2013069190A1 (en) 2011-11-09 2013-05-16 Nec Corporation Mobile communication terminal, communication method, communication system, and control apparatus
WO2013141200A1 (en) 2012-03-19 2013-09-26 日本電気株式会社 Communication node, packet processing method and program
WO2013141191A1 (en) 2012-03-19 2013-09-26 日本電気株式会社 Control apparatus, communication system, node control method and program
WO2013141193A1 (en) 2012-03-19 2013-09-26 日本電気株式会社 Communication system, control device, communication device, information-relaying method, and program
WO2013146885A1 (en) 2012-03-28 2013-10-03 日本電気株式会社 Communication system, upper layer switch, control device, switch control method, and program
WO2013176262A1 (en) 2012-05-25 2013-11-28 日本電気株式会社 Packet transfer system, control device, packet transfer method and program
WO2013183664A1 (en) 2012-06-06 2013-12-12 日本電気株式会社 Switch device, vlan configuration and management method, and program
WO2013187054A1 (en) 2012-06-14 2013-12-19 Nec Corporation Communication system, control apparatus, communication method, control method and program
WO2014002455A1 (en) 2012-06-26 2014-01-03 Nec Corporation Communication method, information processing apparatus, communication system, program, node, and communication terminal
WO2014002481A1 (en) 2012-06-26 2014-01-03 Nec Corporation Communication method, information processing apparatus, communication system, communication terminal, and program
WO2014002460A1 (en) 2012-06-26 2014-01-03 Nec Corporation Communication method, communication system, information processing apparatus, communication terminal, and program
US8681803B2 (en) 2011-09-20 2014-03-25 Nec Corporation Communication system, policy management apparatus, communication method, and program
US8837493B2 (en) 2010-07-06 2014-09-16 Nicira, Inc. Distributed network control apparatus and method
WO2014142094A1 (en) 2013-03-12 2014-09-18 日本電気株式会社 Communication system, physical machine, virtual network management device, and network control method
US8913611B2 (en) 2011-11-15 2014-12-16 Nicira, Inc. Connection identifier assignment and source network address translation
US8958298B2 (en) 2011-08-17 2015-02-17 Nicira, Inc. Centralized logical L3 routing
US8966035B2 (en) 2009-04-01 2015-02-24 Nicira, Inc. Method and apparatus for implementing and managing distributed virtual switches in several hosts and physical forwarding elements
US8964528B2 (en) 2010-07-06 2015-02-24 Nicira, Inc. Method and apparatus for robust packet distribution among hierarchical managed switching elements
US9043452B2 (en) 2011-05-04 2015-05-26 Nicira, Inc. Network control apparatus and method for port isolation
WO2015093561A1 (en) 2013-12-19 2015-06-25 日本電気株式会社 Packet transfer system, controller, and method and program for controlling relay device
US9137107B2 (en) 2011-10-25 2015-09-15 Nicira, Inc. Physical controllers for converting universal flows
US9154433B2 (en) 2011-10-25 2015-10-06 Nicira, Inc. Physical controller
KR20150123337A (en) 2011-04-18 2015-11-03 닛본 덴끼 가부시끼가이샤 Terminal, control device, communication method, communication system, communication module, computer readable storage medium for storing program, and information processing device
US9178910B2 (en) 2010-12-24 2015-11-03 Nec Corporation Communication system, control apparatus, policy management apparatus, communication method, and program
US9197555B2 (en) 2010-08-20 2015-11-24 Nec Corporation Communication system, controller, node controlling method and program
US9203701B2 (en) 2011-10-25 2015-12-01 Nicira, Inc. Network virtualization apparatus and method with scheduling capabilities
US9215210B2 (en) 2014-03-31 2015-12-15 Nicira, Inc. Migrating firewall connection state for a firewall service virtual machine
US9215237B2 (en) 2011-05-23 2015-12-15 Nec Corporation Communication system, control device, communication method, and program
US9215213B2 (en) 2014-02-20 2015-12-15 Nicira, Inc. Method and apparatus for distributing firewall rules
US9225597B2 (en) 2014-03-14 2015-12-29 Nicira, Inc. Managed gateways peering with external router to attract ingress packets
US9237094B2 (en) 2010-11-02 2016-01-12 Nec Corporation Communication system, control apparatus, path controlling method and program
EP2991302A1 (en) * 2014-08-26 2016-03-02 Alcatel Lucent Network system
US9288104B2 (en) 2011-10-25 2016-03-15 Nicira, Inc. Chassis controllers for converting universal flows
US9313129B2 (en) 2014-03-14 2016-04-12 Nicira, Inc. Logical router processing by network controller
US9338091B2 (en) 2014-03-27 2016-05-10 Nicira, Inc. Procedures for efficient cloud service access in a system with multiple tenant logical networks
US9397956B2 (en) 2011-06-02 2016-07-19 Nec Corporation Communication system, control device, forwarding node, and control method and program for communication system
US9401772B2 (en) 2011-01-28 2016-07-26 Nec Corporation Communication system, control device, forwarding node, communication control method, and program
US9413644B2 (en) 2014-03-27 2016-08-09 Nicira, Inc. Ingress ECMP in virtual distributed routing environment
US9419910B2 (en) 2011-09-13 2016-08-16 Nec Corporation Communication system, control apparatus, and communication method
US9419855B2 (en) 2014-03-14 2016-08-16 Nicira, Inc. Static routes for logical routers
US9455901B2 (en) 2013-10-04 2016-09-27 Nicira, Inc. Managing software and hardware forwarding elements to define virtual networks
US9461893B2 (en) 2010-07-23 2016-10-04 Nec Corporation Communication system, node, statistical information collection device, statistical information collection method and program
US9489519B2 (en) 2014-06-30 2016-11-08 Nicira, Inc. Method and apparatus for encrypting data messages after detecting infected VM
US9503321B2 (en) 2014-03-21 2016-11-22 Nicira, Inc. Dynamic routing for logical routers
US9503427B2 (en) 2014-03-31 2016-11-22 Nicira, Inc. Method and apparatus for integrating a service virtual machine
US9503371B2 (en) 2013-09-04 2016-11-22 Nicira, Inc. High availability L3 gateways for logical networks
US9525647B2 (en) 2010-07-06 2016-12-20 Nicira, Inc. Network control apparatus and method for creating and modifying logical switching elements
US9531676B2 (en) 2013-08-26 2016-12-27 Nicira, Inc. Proxy methods for suppressing broadcast traffic in a network
US9544194B2 (en) 2011-09-09 2017-01-10 Nec Corporation Network management service system, control apparatus, method, and program
US9571426B2 (en) 2013-08-26 2017-02-14 Vmware, Inc. Traffic and load aware dynamic queue management
US9575782B2 (en) 2013-10-13 2017-02-21 Nicira, Inc. ARP for logical router
US9577845B2 (en) 2013-09-04 2017-02-21 Nicira, Inc. Multiple active L3 gateways for logical networks
US9582308B2 (en) 2014-03-31 2017-02-28 Nicira, Inc. Auto detecting legitimate IP addresses using spoofguard agents
JP2017506462A (en) * 2014-02-24 2017-03-02 レベル スリー コミュニケーションズ,エルエルシー Control device detection in networks with separate control and forwarding devices
US9590901B2 (en) 2014-03-14 2017-03-07 Nicira, Inc. Route advertisement by managed gateways
US9647883B2 (en) 2014-03-21 2017-05-09 Nicria, Inc. Multiple levels of logical routers
US9680750B2 (en) 2010-07-06 2017-06-13 Nicira, Inc. Use of tunnels to hide network addresses
US9686192B2 (en) 2013-06-28 2017-06-20 Niciria, Inc. Network service slotting
US9692727B2 (en) 2014-12-02 2017-06-27 Nicira, Inc. Context-aware distributed firewall
US9729512B2 (en) 2014-06-04 2017-08-08 Nicira, Inc. Use of stateless marking to speed up stateful firewall rule processing
US9749240B2 (en) 2012-10-24 2017-08-29 Nec Corporation Communication system, virtual machine server, virtual network management apparatus, network control method, and program
US9768980B2 (en) 2014-09-30 2017-09-19 Nicira, Inc. Virtual distributed bridging
US9774537B2 (en) 2014-09-30 2017-09-26 Nicira, Inc. Dynamically adjusting load balancing
US9794186B2 (en) 2014-03-27 2017-10-17 Nicira, Inc. Distributed network address translation for efficient cloud service access
US9825913B2 (en) 2014-06-04 2017-11-21 Nicira, Inc. Use of stateless marking to speed up stateful firewall rule processing
US9825854B2 (en) 2014-03-27 2017-11-21 Nicira, Inc. Host architecture for efficient cloud service access
US9838336B2 (en) 2013-03-06 2017-12-05 Nec Corporation Communication system, control apparatus, forwarding node, control method and program
US9866473B2 (en) 2014-11-14 2018-01-09 Nicira, Inc. Stateful services on stateless clustered edge
US9876672B2 (en) 2007-09-26 2018-01-23 Nicira, Inc. Network operating system for managing and securing networks
US9876714B2 (en) 2014-11-14 2018-01-23 Nicira, Inc. Stateful services on stateless clustered edge
US9887960B2 (en) 2013-08-14 2018-02-06 Nicira, Inc. Providing services for logical networks
US9893988B2 (en) 2014-03-27 2018-02-13 Nicira, Inc. Address resolution using multiple designated instances of a logical router
US9906448B2 (en) 2010-12-10 2018-02-27 Nec Corporation Communication system, control device, node controlling method, and program
US9906494B2 (en) 2014-03-31 2018-02-27 Nicira, Inc. Configuring interactions with a firewall service virtual machine
EP3297212A1 (en) 2010-11-01 2018-03-21 NEC Corporation Communication system, control apparatus, packet forwarding path control method, and program
US9930066B2 (en) 2013-02-12 2018-03-27 Nicira, Inc. Infrastructure level LAN security
US9935876B2 (en) 2012-03-30 2018-04-03 Nec Corporation Communication system, control apparatus, communication apparatus, communication control method, and program
US9952885B2 (en) 2013-08-14 2018-04-24 Nicira, Inc. Generation of configuration files for a DHCP module executing within a virtualized container
US9984036B2 (en) 2013-02-26 2018-05-29 Nec Corporation Communication system, control apparatus, communication method, and program
US9998530B2 (en) 2013-10-15 2018-06-12 Nicira, Inc. Distributed global load-balancing system for software-defined data centers
US9998324B2 (en) 2015-09-30 2018-06-12 Nicira, Inc. Logical L3 processing for L2 hardware switches
US10020960B2 (en) 2014-09-30 2018-07-10 Nicira, Inc. Virtual distributed bridging
US10033579B2 (en) 2012-04-18 2018-07-24 Nicira, Inc. Using transactions to compute and propagate network forwarding state
US10033693B2 (en) 2013-10-01 2018-07-24 Nicira, Inc. Distributed identity-based firewalls
US10038628B2 (en) 2015-04-04 2018-07-31 Nicira, Inc. Route server mode for dynamic routing between logical and physical networks
US10044617B2 (en) 2014-11-14 2018-08-07 Nicira, Inc. Stateful services on stateless clustered edge
US10057157B2 (en) 2015-08-31 2018-08-21 Nicira, Inc. Automatically advertising NAT routes between logical routers
WO2018152303A1 (en) * 2017-02-15 2018-08-23 Edgewise Networks, Inc. Network application security policy generation
US10063458B2 (en) 2013-10-13 2018-08-28 Nicira, Inc. Asymmetric connection with external networks
US10075371B2 (en) 2010-10-19 2018-09-11 Nec Corporation Communication system, control apparatus, packet handling operation setting method, and program
US10079779B2 (en) 2015-01-30 2018-09-18 Nicira, Inc. Implementing logical router uplinks
US10091161B2 (en) 2016-04-30 2018-10-02 Nicira, Inc. Assignment of router ID for logical routers
US10095535B2 (en) 2015-10-31 2018-10-09 Nicira, Inc. Static route types for logical routers
US10103939B2 (en) 2010-07-06 2018-10-16 Nicira, Inc. Network control apparatus and method for populating logical datapath sets
US10129077B2 (en) 2014-09-30 2018-11-13 Nicira, Inc. Configuring and operating a XaaS model in a datacenter
US10129142B2 (en) 2015-08-11 2018-11-13 Nicira, Inc. Route configuration for logical router
US10135727B2 (en) 2016-04-29 2018-11-20 Nicira, Inc. Address grouping for distributed service rules
US10153973B2 (en) 2016-06-29 2018-12-11 Nicira, Inc. Installation of routing tables for logical router in route server mode
US10154067B2 (en) 2017-02-10 2018-12-11 Edgewise Networks, Inc. Network application security policy enforcement
US10182035B2 (en) 2016-06-29 2019-01-15 Nicira, Inc. Implementing logical network security on a hardware switch
US10193862B2 (en) 2016-11-29 2019-01-29 Vmware, Inc. Security policy analysis based on detecting new network port connections
US10204122B2 (en) 2015-09-30 2019-02-12 Nicira, Inc. Implementing an interface between tuple and message-driven control entities
US10212071B2 (en) 2016-12-21 2019-02-19 Nicira, Inc. Bypassing a load balancer in a return path of network traffic
US10225184B2 (en) 2015-06-30 2019-03-05 Nicira, Inc. Redirecting traffic in a virtual distributed router environment
US10230576B2 (en) 2015-09-30 2019-03-12 Nicira, Inc. Managing administrative statuses of hardware VTEPs
US10237123B2 (en) 2016-12-21 2019-03-19 Nicira, Inc. Dynamic recovery from a split-brain failure in edge nodes
US10250443B2 (en) 2014-09-30 2019-04-02 Nicira, Inc. Using physical location to modify behavior of a distributed virtual network element
US10250553B2 (en) 2015-11-03 2019-04-02 Nicira, Inc. ARP offloading for managed hardware forwarding elements
US10263828B2 (en) 2015-09-30 2019-04-16 Nicira, Inc. Preventing concurrent distribution of network data to a hardware switch by multiple controllers
US10313186B2 (en) 2015-08-31 2019-06-04 Nicira, Inc. Scalable controller for hardware VTEPS
US10333849B2 (en) 2016-04-28 2019-06-25 Nicira, Inc. Automatic configuration of logical routers on edge nodes
US10333983B2 (en) 2016-08-30 2019-06-25 Nicira, Inc. Policy definition and enforcement for a network virtualization platform
US10341236B2 (en) 2016-09-30 2019-07-02 Nicira, Inc. Anycast edge service gateways
US10348685B2 (en) 2016-04-29 2019-07-09 Nicira, Inc. Priority allocation for distributed service rules
US10348599B2 (en) 2017-11-10 2019-07-09 Edgewise Networks, Inc. Automated load balancer discovery
US10374827B2 (en) 2017-11-14 2019-08-06 Nicira, Inc. Identifier that maps to different networks at different datacenters
US10411912B2 (en) 2015-04-17 2019-09-10 Nicira, Inc. Managing tunnel endpoints for facilitating creation of logical networks
US10439985B2 (en) 2017-02-15 2019-10-08 Edgewise Networks, Inc. Network application security policy generation
US10447618B2 (en) 2015-09-30 2019-10-15 Nicira, Inc. IP aliases in logical networks with hardware switches
US10454758B2 (en) 2016-08-31 2019-10-22 Nicira, Inc. Edge node cluster network redundancy and fast convergence using an underlay anycast VTEP IP
US10484515B2 (en) 2017-01-30 2019-11-19 Nicira, Inc. Implementing logical metadata proxy servers in logical networks

Families Citing this family (97)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9661112B2 (en) * 2007-02-22 2017-05-23 International Business Machines Corporation System and methods for providing server virtualization assistance
US8320249B2 (en) * 2007-03-07 2012-11-27 Broadcom Corporation Method and system for controlling network access on a per-flow basis
US8091094B2 (en) * 2007-10-10 2012-01-03 Sap Ag Methods and systems for ambistateful backend control
US8031606B2 (en) 2008-06-24 2011-10-04 Intel Corporation Packet switching
WO2010103909A1 (en) * 2009-03-09 2010-09-16 日本電気株式会社 OpenFlow COMMUNICATION SYSTEM AND OpenFlow COMMUNICATION METHOD
US8713060B2 (en) 2009-03-31 2014-04-29 Amazon Technologies, Inc. Control service for relational data management
US8332365B2 (en) 2009-03-31 2012-12-11 Amazon Technologies, Inc. Cloning and recovery of data volumes
US9705888B2 (en) * 2009-03-31 2017-07-11 Amazon Technologies, Inc. Managing security groups for data instances
US9207984B2 (en) * 2009-03-31 2015-12-08 Amazon Technologies, Inc. Monitoring and automatic scaling of data volumes
JP5446040B2 (en) * 2009-09-28 2014-03-19 日本電気株式会社 Computer system and virtual machine migration method
US9135283B2 (en) * 2009-10-07 2015-09-15 Amazon Technologies, Inc. Self-service configuration for data environment
JP5672235B2 (en) * 2009-10-19 2015-02-18 日本電気株式会社 Communication system, flow control device, flow table update method and program
US8335765B2 (en) 2009-10-26 2012-12-18 Amazon Technologies, Inc. Provisioning and managing replicated data instances
US8676753B2 (en) 2009-10-26 2014-03-18 Amazon Technologies, Inc. Monitoring of replicated data instances
JP5372711B2 (en) * 2009-11-13 2013-12-18 アラクサラネットワークス株式会社 Devices and systems that effectively use multiple authentication servers
MX2012005778A (en) * 2009-11-20 2012-06-13 Ericsson Telefon Ab L M Controlling packet filter installation in a user equipment.
CN101741737B (en) * 2009-12-08 2013-01-16 中兴通讯股份有限公司 Maintenance method and device of route table
US9088432B2 (en) * 2010-02-23 2015-07-21 Nec Corporation Remote control system, remote control method and program for remote control
US8897134B2 (en) * 2010-06-25 2014-11-25 Telefonaktiebolaget L M Ericsson (Publ) Notifying a controller of a change to a packet forwarding configuration of a network element over a communication channel
US8782434B1 (en) 2010-07-15 2014-07-15 The Research Foundation For The State University Of New York System and method for validating program execution at run-time
JP5804054B2 (en) 2010-10-15 2015-11-04 日本電気株式会社 Communication system, control device, node, processing rule setting method and program
JP5590126B2 (en) * 2010-12-01 2014-09-17 日本電気株式会社 Communication system, control device, communication method, and program
US9001827B2 (en) 2010-12-17 2015-04-07 Big Switch Networks, Inc. Methods for configuring network switches
WO2012090354A1 (en) * 2010-12-27 2012-07-05 Nec Corporation Communication system and communication method
US8625597B2 (en) 2011-01-07 2014-01-07 Jeda Networks, Inc. Methods, systems and apparatus for the interconnection of fibre channel over ethernet devices
US8559433B2 (en) 2011-01-07 2013-10-15 Jeda Networks, Inc. Methods, systems and apparatus for the servicing of fibre channel fabric login frames
US8811399B2 (en) 2011-01-07 2014-08-19 Jeda Networks, Inc. Methods, systems and apparatus for the interconnection of fibre channel over ethernet devices using a fibre channel over ethernet interconnection apparatus controller
US9178944B2 (en) 2011-01-07 2015-11-03 Jeda Networks, Inc. Methods, systems and apparatus for the control of interconnection of fibre channel over ethernet devices
US8559335B2 (en) 2011-01-07 2013-10-15 Jeda Networks, Inc. Methods for creating virtual links between fibre channel over ethernet nodes for converged network adapters
US9071630B2 (en) 2011-01-07 2015-06-30 Jeda Networks, Inc. Methods for the interconnection of fibre channel over ethernet devices using a trill network
US9106579B2 (en) 2011-01-07 2015-08-11 Jeda Networks, Inc. Methods, systems and apparatus for utilizing an iSNS server in a network of fibre channel over ethernet devices
US9071629B2 (en) 2011-01-07 2015-06-30 Jeda Networks, Inc. Methods for the interconnection of fibre channel over ethernet devices using shortest path bridging
JP5717057B2 (en) * 2011-01-17 2015-05-13 日本電気株式会社 Network system, controller, switch, and traffic monitoring method
WO2012115058A1 (en) * 2011-02-21 2012-08-30 日本電気株式会社 Communication system, database, control device, communication method and program
WO2012131695A1 (en) * 2011-03-31 2012-10-04 Tejas Networks Limited A method and system of protection switching in a network element
US9065815B2 (en) * 2011-04-15 2015-06-23 Nec Corporation Computer system, controller, and method of controlling network access policy
US9185056B2 (en) * 2011-09-20 2015-11-10 Big Switch Networks, Inc. System and methods for controlling network traffic through virtual switches
JP5943410B2 (en) * 2011-09-21 2016-07-05 日本電気株式会社 Communication device, control device, communication system, communication control method, and program
US10142160B1 (en) * 2011-10-04 2018-11-27 Big Switch Networks, Inc. System and methods for managing network hardware address requests with a controller
US8856384B2 (en) 2011-10-14 2014-10-07 Big Switch Networks, Inc. System and methods for managing network protocol address assignment with a controller
WO2013073448A1 (en) * 2011-11-15 2013-05-23 独立行政法人科学技術振興機構 Packet data extraction device, control method for packet data extraction device, control program, and computer-readable recording medium
KR101887581B1 (en) 2011-12-26 2018-08-14 한국전자통신연구원 Flow-based packet transport device and packet management method thereof
US9036636B1 (en) * 2012-02-06 2015-05-19 Big Switch Networks, Inc. System and methods for managing network packet broadcasting
EP2819356A4 (en) * 2012-02-20 2015-09-30 Nec Corp Network system, and method for improving resource usage
US9185166B2 (en) * 2012-02-28 2015-11-10 International Business Machines Corporation Disjoint multi-pathing for a data center network
US9264295B1 (en) * 2012-03-02 2016-02-16 Big Switch Networks, Inc. Systems and methods for forwarding broadcast network packets with a controller
US20150052576A1 (en) * 2012-04-03 2015-02-19 Nec Corporation Network system, controller and packet authenticating method
JP5978384B2 (en) 2012-04-12 2016-08-24 ▲ホア▼▲ウェイ▼技術有限公司Huawei Technologies Co.,Ltd. Method for receiving information, method for transmitting information and apparatus thereof
US20130290237A1 (en) * 2012-04-27 2013-10-31 International Business Machines Corporation Discovery and grouping of related computing resources using machine learning
US20150124595A1 (en) 2012-05-01 2015-05-07 Nec Corporation Communication system, access control apparatus, switch, network control method, and program
US8789135B1 (en) 2012-06-15 2014-07-22 Google Inc. Scalable stateful firewall design in openflow based networks
US20140040459A1 (en) * 2012-08-01 2014-02-06 Hewlett-Packard Development Company, L.P. System and method for data communication using a classified flow table in openflow networks
CN102843362B (en) * 2012-08-08 2016-05-04 唐稳杰 A method of using arp defense method for tcam
US9063721B2 (en) 2012-09-14 2015-06-23 The Research Foundation For The State University Of New York Continuous run-time validation of program execution: a practical approach
US9069782B2 (en) 2012-10-01 2015-06-30 The Research Foundation For The State University Of New York System and method for security and privacy aware virtual machine checkpointing
US9787567B1 (en) 2013-01-30 2017-10-10 Big Switch Networks, Inc. Systems and methods for network traffic monitoring
US9008080B1 (en) * 2013-02-25 2015-04-14 Big Switch Networks, Inc. Systems and methods for controlling switches to monitor network traffic
US9515873B2 (en) * 2013-03-12 2016-12-06 Dell Products L.P. System and method for management of virtual sub-networks
US9571610B2 (en) * 2013-03-15 2017-02-14 International Business Machines Corporation Dynamic port type detection
US10075470B2 (en) 2013-04-19 2018-09-11 Nicira, Inc. Framework for coordination between endpoint security and network security services
US9674193B1 (en) * 2013-07-30 2017-06-06 Juniper Networks, Inc. Aggregation and disbursement of licenses in distributed networks
PL404986A1 (en) * 2013-08-05 2015-02-16 Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie Device for routing of packets through multiple paths in the data communication system and method of its application
US10009371B2 (en) 2013-08-09 2018-06-26 Nicira Inc. Method and system for managing network storm
CN104468357B (en) * 2013-09-16 2019-07-12 中兴通讯股份有限公司 Multipolarity method, the multilevel flow table processing method and processing device of flow table
JP6111974B2 (en) * 2013-10-22 2017-04-12 富士通株式会社 Transfer device, control device, and transfer method
US9798561B2 (en) 2013-10-31 2017-10-24 Vmware, Inc. Guarded virtual machines
US9819551B2 (en) 2013-11-20 2017-11-14 Big Switch Networks, Inc. Systems and methods for testing networks with a controller
CN108667853A (en) * 2013-11-22 2018-10-16 华为技术有限公司 The detection method and device of malicious attack
CN104683231A (en) * 2013-11-29 2015-06-03 英业达科技有限公司 Rout control method and route control device
US10277717B2 (en) 2013-12-15 2019-04-30 Nicira, Inc. Network introspection in an operating system
US8910294B1 (en) * 2013-12-18 2014-12-09 State Farm Mutual Automobile Insurance Company System and method for application failure testing in a cloud computing environment
US9654377B2 (en) * 2014-01-30 2017-05-16 Thomson Licensing Per port ethernet packet processing mode by device type
US9369478B2 (en) 2014-02-06 2016-06-14 Nicira, Inc. OWL-based intelligent security audit
US9544182B2 (en) 2014-02-19 2017-01-10 Steven Waldbusser Monitoring gateway systems and methods for openflow type networks
CN104869178A (en) * 2014-02-21 2015-08-26 中兴通讯股份有限公司 IP address distribution method, controller and gateway device in SDN-EPS
US9608913B1 (en) * 2014-02-24 2017-03-28 Google Inc. Weighted load balancing in a multistage network
WO2015147793A1 (en) * 2014-03-25 2015-10-01 Hewlett-Packard Development Company, L.P. Transmitting network traffic in accordance with network traffic rules
US10218617B2 (en) * 2014-07-15 2019-02-26 Nec Corporation Method and network device for handling packets in a network by means of forwarding tables
US9813312B2 (en) 2014-07-21 2017-11-07 Big Switch Networks, Inc. Systems and methods for performing debugging operations on networks using a controller
US10270645B2 (en) 2014-07-21 2019-04-23 Big Switch Networks, Inc. Systems and methods for handling link aggregation failover with a controller
US9743367B2 (en) * 2014-09-18 2017-08-22 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Link layer discovery protocol (LLDP) on multiple nodes of a distributed fabric
US10237354B2 (en) * 2014-09-25 2019-03-19 Intel Corporation Technologies for offloading a virtual service endpoint to a network interface card
US9794331B1 (en) * 2014-09-29 2017-10-17 Amazon Technologies, Inc. Block allocation based on server utilization
US9813323B2 (en) 2015-02-10 2017-11-07 Big Switch Networks, Inc. Systems and methods for controlling switches to capture and monitor network traffic
US9716700B2 (en) * 2015-02-19 2017-07-25 International Business Machines Corporation Code analysis for providing data privacy in ETL systems
US9967134B2 (en) 2015-04-06 2018-05-08 Nicira, Inc. Reduction of network churn based on differences in input state
US9680706B2 (en) 2015-06-30 2017-06-13 Nicira, Inc. Federated firewall management for moving workload across data centers
US9967182B2 (en) 2015-07-31 2018-05-08 Nicira, Inc. Enabling hardware switches to perform logical routing functionalities
US9819581B2 (en) 2015-07-31 2017-11-14 Nicira, Inc. Configuring a hardware switch as an edge node for a logical router
US9847938B2 (en) 2015-07-31 2017-12-19 Nicira, Inc. Configuring logical routers on hardware switches
TWI560574B (en) * 2015-12-01 2016-12-01 Chunghwa Telecom Co Ltd
US9992112B2 (en) 2015-12-15 2018-06-05 Nicira, Inc. Transactional controls for supplying control plane data to managed hardware forwarding elements
US9917799B2 (en) 2015-12-15 2018-03-13 Nicira, Inc. Transactional controls for supplying control plane data to managed hardware forwarding elements
US9998375B2 (en) 2015-12-15 2018-06-12 Nicira, Inc. Transactional controls for supplying control plane data to managed hardware forwarding elements
US10462007B2 (en) * 2016-06-27 2019-10-29 Cisco Technology, Inc. Network address transparency through user role authentication
US10419327B2 (en) 2017-10-12 2019-09-17 Big Switch Networks, Inc. Systems and methods for controlling switches to record network packets using a traffic monitoring network
US10298611B1 (en) * 2018-12-10 2019-05-21 Securitymetrics, Inc. Network vulnerability assessment

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5113499A (en) * 1989-04-28 1992-05-12 Sprint International Communications Corp. Telecommunication access management system for a packet switching network
US6084892A (en) * 1997-03-11 2000-07-04 Bell Atlantic Networks Services, Inc. Public IP transport network
US20030216144A1 (en) * 2002-03-01 2003-11-20 Roese John J. Using signal characteristics to locate devices in a data network
US20040068668A1 (en) * 2002-10-08 2004-04-08 Broadcom Corporation Enterprise wireless local area network switching system
US20050198337A1 (en) * 2004-01-26 2005-09-08 Nortel Networks Limited Multiple simultaneous wireless connections in a wireless local area network

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5113499A (en) * 1989-04-28 1992-05-12 Sprint International Communications Corp. Telecommunication access management system for a packet switching network
US6084892A (en) * 1997-03-11 2000-07-04 Bell Atlantic Networks Services, Inc. Public IP transport network
US20030216144A1 (en) * 2002-03-01 2003-11-20 Roese John J. Using signal characteristics to locate devices in a data network
US20040068668A1 (en) * 2002-10-08 2004-04-08 Broadcom Corporation Enterprise wireless local area network switching system
US20050198337A1 (en) * 2004-01-26 2005-09-08 Nortel Networks Limited Multiple simultaneous wireless connections in a wireless local area network

Cited By (275)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9876672B2 (en) 2007-09-26 2018-01-23 Nicira, Inc. Network operating system for managing and securing networks
US8966035B2 (en) 2009-04-01 2015-02-24 Nicira, Inc. Method and apparatus for implementing and managing distributed virtual switches in several hosts and physical forwarding elements
US9590919B2 (en) 2009-04-01 2017-03-07 Nicira, Inc. Method and apparatus for implementing and managing virtual switches
CN102783098A (en) * 2010-03-05 2012-11-14 日本电气株式会社 Communication system, path control apparatus, packet forwarding apparatus and path control method
CN102783098B (en) * 2010-03-05 2016-01-20 日本电气株式会社 Communication system, a path control device, the packet forwarding device and path control method
US20130003745A1 (en) * 2010-03-24 2013-01-03 Kouichi Nishimura Information system, control device, method of managing virtual network, and program
US9007903B2 (en) 2010-07-06 2015-04-14 Nicira, Inc. Managing a network by controlling edge and non-edge switching elements
US10320585B2 (en) 2010-07-06 2019-06-11 Nicira, Inc. Network control apparatus and method for creating and modifying logical switching elements
US10326660B2 (en) 2010-07-06 2019-06-18 Nicira, Inc. Network virtualization apparatus and method
US9112811B2 (en) 2010-07-06 2015-08-18 Nicira, Inc. Managed switching elements used as extenders
US9106587B2 (en) 2010-07-06 2015-08-11 Nicira, Inc. Distributed network control system with one master controller per managed switching element
US9077664B2 (en) 2010-07-06 2015-07-07 Nicira, Inc. One-hop packet processing in a network with managed switching elements
US9231891B2 (en) 2010-07-06 2016-01-05 Nicira, Inc. Deployment of hierarchical managed switching elements
US10038597B2 (en) 2010-07-06 2018-07-31 Nicira, Inc. Mesh architectures for managed switching elements
US9300603B2 (en) 2010-07-06 2016-03-29 Nicira, Inc. Use of rich context tags in logical data processing
US9049153B2 (en) 2010-07-06 2015-06-02 Nicira, Inc. Logical packet processing pipeline that retains state information to effectuate efficient processing of packets
US9008087B2 (en) 2010-07-06 2015-04-14 Nicira, Inc. Processing requests in a network control system with multiple controller instances
US9306875B2 (en) 2010-07-06 2016-04-05 Nicira, Inc. Managed switch architectures for implementing logical datapath sets
US9172663B2 (en) 2010-07-06 2015-10-27 Nicira, Inc. Method and apparatus for replicating network information base in a distributed network control system with multiple controller instances
US8964528B2 (en) 2010-07-06 2015-02-24 Nicira, Inc. Method and apparatus for robust packet distribution among hierarchical managed switching elements
US8964598B2 (en) 2010-07-06 2015-02-24 Nicira, Inc. Mesh architectures for managed switching elements
US9391928B2 (en) 2010-07-06 2016-07-12 Nicira, Inc. Method and apparatus for interacting with a network information base in a distributed network control system with multiple controller instances
US10103939B2 (en) 2010-07-06 2018-10-16 Nicira, Inc. Network control apparatus and method for populating logical datapath sets
US8959215B2 (en) 2010-07-06 2015-02-17 Nicira, Inc. Network virtualization
US8958292B2 (en) 2010-07-06 2015-02-17 Nicira, Inc. Network control apparatus and method with port security controls
US8913483B2 (en) 2010-07-06 2014-12-16 Nicira, Inc. Fault tolerant managed switching element architecture
US8966040B2 (en) 2010-07-06 2015-02-24 Nicira, Inc. Use of network information base structure to establish communication between applications
US9692655B2 (en) 2010-07-06 2017-06-27 Nicira, Inc. Packet processing in a network with hierarchical managed switching elements
US8880468B2 (en) 2010-07-06 2014-11-04 Nicira, Inc. Secondary storage architecture for a network control system that utilizes a primary network information base
US9525647B2 (en) 2010-07-06 2016-12-20 Nicira, Inc. Network control apparatus and method for creating and modifying logical switching elements
US9680750B2 (en) 2010-07-06 2017-06-13 Nicira, Inc. Use of tunnels to hide network addresses
US8842679B2 (en) 2010-07-06 2014-09-23 Nicira, Inc. Control system that elects a master controller instance for switching elements
US8837493B2 (en) 2010-07-06 2014-09-16 Nicira, Inc. Distributed network control apparatus and method
US10021019B2 (en) 2010-07-06 2018-07-10 Nicira, Inc. Packet processing for logical datapath sets
US9363210B2 (en) 2010-07-06 2016-06-07 Nicira, Inc. Distributed network control system with one master controller per logical datapath set
US9461893B2 (en) 2010-07-23 2016-10-04 Nec Corporation Communication system, node, statistical information collection device, statistical information collection method and program
US9197555B2 (en) 2010-08-20 2015-11-24 Nec Corporation Communication system, controller, node controlling method and program
WO2012050071A1 (en) 2010-10-14 2012-04-19 日本電気株式会社 Communication system, control device, method for setting processing rules, and program
US10075371B2 (en) 2010-10-19 2018-09-11 Nec Corporation Communication system, control apparatus, packet handling operation setting method, and program
EP3297212A1 (en) 2010-11-01 2018-03-21 NEC Corporation Communication system, control apparatus, packet forwarding path control method, and program
US9237094B2 (en) 2010-11-02 2016-01-12 Nec Corporation Communication system, control apparatus, path controlling method and program
WO2012070173A1 (en) 2010-11-22 2012-05-31 Nec Corporation Communication system, communication device, controller, and method and program for controlling forwarding path of packet flow
US8842674B2 (en) 2010-11-22 2014-09-23 Nec Corporation Communication system, communication device, controller, and method and program for controlling forwarding path of packet flow
US8842673B2 (en) 2010-11-22 2014-09-23 Nec Corporation Communication system, communication device, controller, and method and program for controlling forwarding path of packet flow
US9231868B2 (en) 2010-11-22 2016-01-05 Nec Corporation Communication system, communication device, controller, and method and program for controlling forwarding path of packet flow
US9497118B2 (en) 2010-11-22 2016-11-15 Nec Corporation Communication system, communication device, controller, and method and program for controlling forwarding path of packet flow
US9203754B2 (en) 2010-11-22 2015-12-01 Nec Corporation Communication system, communication device, controller, and method and program for controlling forwarding path of packet flow
US9906448B2 (en) 2010-12-10 2018-02-27 Nec Corporation Communication system, control device, node controlling method, and program
WO2012081145A1 (en) 2010-12-13 2012-06-21 Nec Corporation Communication path control system, path control device, communication path control method, and path control program
WO2012081146A1 (en) 2010-12-16 2012-06-21 Nec Corporation Communication system, control apparatus, communication method, and program
WO2012081721A1 (en) 2010-12-17 2012-06-21 日本電気株式会社 Communication system, node, packet transfer method and program
US9178910B2 (en) 2010-12-24 2015-11-03 Nec Corporation Communication system, control apparatus, policy management apparatus, communication method, and program
KR20130099221A (en) 2010-12-28 2013-09-05 닛본 덴끼 가부시끼가이샤 Information system, control device, virtual network provision method and program
US10044830B2 (en) 2010-12-28 2018-08-07 Nec Corporation Information system, control apparatus, method of providing virtual network, and program
WO2012090355A1 (en) 2010-12-28 2012-07-05 Nec Corporation Communication system, forwarding node, received packet process method, and program
WO2012090996A1 (en) 2010-12-28 2012-07-05 日本電気株式会社 Information system, control device, virtual network provision method and program
KR20150092351A (en) 2010-12-28 2015-08-12 닛본 덴끼 가부시끼가이샤 Information system, control device, virtual network provision method and program
US9276852B2 (en) 2010-12-28 2016-03-01 Nec Corporation Communication system, forwarding node, received packet process method, and program
US9363182B2 (en) 2011-01-20 2016-06-07 Nec Corporation Communication system, control device, policy management device, communication method, and program
WO2012098596A1 (en) 2011-01-20 2012-07-26 Nec Corporation Communication system, control device, policy management device, communication method, and program
US9479323B2 (en) 2011-01-28 2016-10-25 Nec Corporation Communication system, forwarding node, control device, communication control method, and program
WO2012101689A1 (en) 2011-01-28 2012-08-02 Nec Corporation Communication system, forwarding node, control device, communication control method, and program
US9401772B2 (en) 2011-01-28 2016-07-26 Nec Corporation Communication system, control device, forwarding node, communication control method, and program
US9887920B2 (en) 2011-04-18 2018-02-06 Nec Corporation Terminal, control device, communication method, communication system, communication module, program, and information processing device
US9397949B2 (en) 2011-04-18 2016-07-19 Nec Corporation Terminal, control device, communication method, communication system, communication module, program, and information processing device
US9338090B2 (en) 2011-04-18 2016-05-10 Nec Corporation Terminal, control device, communication method, communication system, communication module, program, and information processing device
KR20150123337A (en) 2011-04-18 2015-11-03 닛본 덴끼 가부시끼가이샤 Terminal, control device, communication method, communication system, communication module, computer readable storage medium for storing program, and information processing device
WO2012144190A1 (en) 2011-04-18 2012-10-26 Nec Corporation Terminal, control device, communication method,communication system, communication module, program, and information processing device
WO2012144203A1 (en) 2011-04-18 2012-10-26 Nec Corporation Terminal, control device, communication method, communication system, communication module,program, and information processing device
US9215611B2 (en) 2011-04-18 2015-12-15 Nec Corporation Terminal, control device, communication method, communication system, communication module, program, and information processing device
EP2645641A1 (en) * 2011-04-21 2013-10-02 Nec Corporation Communication system, control device, communication method, and program
CN103299589A (en) * 2011-04-21 2013-09-11 日本电气株式会社 Communication system, control device, communication method, and program
EP2645641A4 (en) * 2011-04-21 2014-12-03 Nec Corp Communication system, control device, communication method, and program
WO2012144583A1 (en) 2011-04-21 2012-10-26 日本電気株式会社 Communication system, control device, communication method, and program
US9043452B2 (en) 2011-05-04 2015-05-26 Nicira, Inc. Network control apparatus and method for port isolation
US9215237B2 (en) 2011-05-23 2015-12-15 Nec Corporation Communication system, control device, communication method, and program
US9397956B2 (en) 2011-06-02 2016-07-19 Nec Corporation Communication system, control device, forwarding node, and control method and program for communication system
WO2012169164A1 (en) 2011-06-06 2012-12-13 Nec Corporation Communication system, control device, and processing rule setting method and program
WO2013022082A1 (en) 2011-08-11 2013-02-14 日本電気株式会社 Packet forwarding system, control device, packet forwarding method and program
US9461831B2 (en) 2011-08-11 2016-10-04 Nec Corporation Packet forwarding system, control apparatus, packet forwarding method, and program
US9369426B2 (en) 2011-08-17 2016-06-14 Nicira, Inc. Distributed logical L3 routing
US9185069B2 (en) 2011-08-17 2015-11-10 Nicira, Inc. Handling reverse NAT in logical L3 routing
US8958298B2 (en) 2011-08-17 2015-02-17 Nicira, Inc. Centralized logical L3 routing
US9059999B2 (en) 2011-08-17 2015-06-16 Nicira, Inc. Load balancing in a logical pipeline
US9319375B2 (en) 2011-08-17 2016-04-19 Nicira, Inc. Flow templating in logical L3 routing
US9350696B2 (en) 2011-08-17 2016-05-24 Nicira, Inc. Handling NAT in logical L3 routing
US9356906B2 (en) 2011-08-17 2016-05-31 Nicira, Inc. Logical L3 routing with DHCP
US10027584B2 (en) 2011-08-17 2018-07-17 Nicira, Inc. Distributed logical L3 routing
US9276897B2 (en) 2011-08-17 2016-03-01 Nicira, Inc. Distributed logical L3 routing
US9407599B2 (en) 2011-08-17 2016-08-02 Nicira, Inc. Handling NAT migration in logical L3 routing
US9461960B2 (en) 2011-08-17 2016-10-04 Nicira, Inc. Logical L3 daemon
WO2013031175A1 (en) 2011-08-29 2013-03-07 Nec Corporation Communication system, control device, node, node control method, and program
JP2013048364A (en) * 2011-08-29 2013-03-07 Nec Corp Communication system, control device, packet transfer method, and program
US9509608B2 (en) 2011-09-01 2016-11-29 Nec Corporation Communication terminal, communication method, communication system, and program
WO2013031233A1 (en) 2011-09-01 2013-03-07 Nec Corporation Communication terminal, communication method, communication system, and program
US9544194B2 (en) 2011-09-09 2017-01-10 Nec Corporation Network management service system, control apparatus, method, and program
US9419910B2 (en) 2011-09-13 2016-08-16 Nec Corporation Communication system, control apparatus, and communication method
US8681803B2 (en) 2011-09-20 2014-03-25 Nec Corporation Communication system, policy management apparatus, communication method, and program
WO2013042374A1 (en) 2011-09-21 2013-03-28 Nec Corporation Communication apparatus, control apparatus, communication system, communication control method, and program
WO2013042358A1 (en) 2011-09-21 2013-03-28 Nec Corporation Communication apparatus, communication system, communication control method, and program
WO2013042346A1 (en) 2011-09-21 2013-03-28 Nec Corporation Communication apparatus, communication system, communication control method, and computer program
US9954793B2 (en) 2011-10-25 2018-04-24 Nicira, Inc. Chassis controller
US9300593B2 (en) 2011-10-25 2016-03-29 Nicira, Inc. Scheduling distribution of logical forwarding plane data
US9306864B2 (en) 2011-10-25 2016-04-05 Nicira, Inc. Scheduling distribution of physical control plane data
US9407566B2 (en) 2011-10-25 2016-08-02 Nicira, Inc. Distributed network control system
US9319338B2 (en) 2011-10-25 2016-04-19 Nicira, Inc. Tunnel creation
US9602421B2 (en) 2011-10-25 2017-03-21 Nicira, Inc. Nesting transaction updates to minimize communication
US9288104B2 (en) 2011-10-25 2016-03-15 Nicira, Inc. Chassis controllers for converting universal flows
US9203701B2 (en) 2011-10-25 2015-12-01 Nicira, Inc. Network virtualization apparatus and method with scheduling capabilities
US9319336B2 (en) 2011-10-25 2016-04-19 Nicira, Inc. Scheduling distribution of logical control plane data
US9178833B2 (en) 2011-10-25 2015-11-03 Nicira, Inc. Chassis controller
US9246833B2 (en) 2011-10-25 2016-01-26 Nicira, Inc. Pull-based state dissemination between managed forwarding elements
US9231882B2 (en) 2011-10-25 2016-01-05 Nicira, Inc. Maintaining quality of service in shared forwarding elements managed by a network control system
US9253109B2 (en) 2011-10-25 2016-02-02 Nicira, Inc. Communication channel for distributed network control system
US9154433B2 (en) 2011-10-25 2015-10-06 Nicira, Inc. Physical controller
US9137107B2 (en) 2011-10-25 2015-09-15 Nicira, Inc. Physical controllers for converting universal flows
US9319337B2 (en) 2011-10-25 2016-04-19 Nicira, Inc. Universal physical control plane
EP3432525A2 (en) 2011-10-28 2019-01-23 NEC Corporation Control apparatus, communication system, virtual network management method, and program
WO2013062070A1 (en) 2011-10-28 2013-05-02 日本電気株式会社 Control apparatus, communication system, virtual network management method, and program
WO2013069190A1 (en) 2011-11-09 2013-05-16 Nec Corporation Mobile communication terminal, communication method, communication system, and control apparatus
US9697030B2 (en) 2011-11-15 2017-07-04 Nicira, Inc. Connection identifier assignment and source network address translation
US10191763B2 (en) 2011-11-15 2019-01-29 Nicira, Inc. Architecture of networks with middleboxes
US10235199B2 (en) 2011-11-15 2019-03-19 Nicira, Inc. Migrating middlebox state for distributed middleboxes
US10310886B2 (en) 2011-11-15 2019-06-04 Nicira, Inc. Network control system for configuring middleboxes
US10089127B2 (en) 2011-11-15 2018-10-02 Nicira, Inc. Control plane interface for logical middlebox services
US9195491B2 (en) 2011-11-15 2015-11-24 Nicira, Inc. Migrating middlebox state for distributed middleboxes
US9172603B2 (en) 2011-11-15 2015-10-27 Nicira, Inc. WAN optimizer for logical networks
US9306909B2 (en) 2011-11-15 2016-04-05 Nicira, Inc. Connection identifier assignment and source network address translation
US8913611B2 (en) 2011-11-15 2014-12-16 Nicira, Inc. Connection identifier assignment and source network address translation
US9015823B2 (en) 2011-11-15 2015-04-21 Nicira, Inc. Firewalls in logical networks
US8966029B2 (en) 2011-11-15 2015-02-24 Nicira, Inc. Network control system for configuring middleboxes
US8966024B2 (en) 2011-11-15 2015-02-24 Nicira, Inc. Architecture of networks with middleboxes
US9697033B2 (en) 2011-11-15 2017-07-04 Nicira, Inc. Architecture of networks with middleboxes
US9552219B2 (en) 2011-11-15 2017-01-24 Nicira, Inc. Migrating middlebox state for distributed middleboxes
US9558027B2 (en) 2011-11-15 2017-01-31 Nicira, Inc. Network control system for configuring middleboxes
US20150003291A1 (en) * 2012-03-19 2015-01-01 Nec Corporation Control apparatus, communication system, communication method, and program
KR20140143798A (en) 2012-03-19 2014-12-17 닛본 덴끼 가부시끼가이샤 Communication system, control device, communication device, information-relaying method, and program
KR20140143803A (en) 2012-03-19 2014-12-17 닛본 덴끼 가부시끼가이샤 Control apparatus, communication system, node control method and program
US9596129B2 (en) 2012-03-19 2017-03-14 Nec Corporation Communication system, control apparatus, communication apparatus, information-relaying method, and program
WO2013141191A1 (en) 2012-03-19 2013-09-26 日本電気株式会社 Control apparatus, communication system, node control method and program
US9769064B2 (en) 2012-03-19 2017-09-19 Nec Corporation Communication node, packet processing method and program
WO2013141200A1 (en) 2012-03-19 2013-09-26 日本電気株式会社 Communication node, packet processing method and program
WO2013141193A1 (en) 2012-03-19 2013-09-26 日本電気株式会社 Communication system, control device, communication device, information-relaying method, and program
WO2013146885A1 (en) 2012-03-28 2013-10-03 日本電気株式会社 Communication system, upper layer switch, control device, switch control method, and program
US9515926B2 (en) 2012-03-28 2016-12-06 Nec Corporation Communication system, upper layer switch, control apparatus, switch control method, and program
US9935876B2 (en) 2012-03-30 2018-04-03 Nec Corporation Communication system, control apparatus, communication apparatus, communication control method, and program
US10033579B2 (en) 2012-04-18 2018-07-24 Nicira, Inc. Using transactions to compute and propagate network forwarding state
US10135676B2 (en) 2012-04-18 2018-11-20 Nicira, Inc. Using transactions to minimize churn in a distributed network control system
US9832114B2 (en) 2012-05-25 2017-11-28 Nec Corporation Packet forwarding system, control apparatus, packet forwarding method, and program
WO2013176262A1 (en) 2012-05-25 2013-11-28 日本電気株式会社 Packet transfer system, control device, packet transfer method and program
US9735982B2 (en) 2012-06-06 2017-08-15 Nec Corporation Switch apparatus, VLAN setting management method, and program
WO2013183664A1 (en) 2012-06-06 2013-12-12 日本電気株式会社 Switch device, vlan configuration and management method, and program
WO2013187054A1 (en) 2012-06-14 2013-12-19 Nec Corporation Communication system, control apparatus, communication method, control method and program
US10212084B2 (en) 2012-06-14 2019-02-19 Nec Corporation Communication system, control apparatus, communication method, control method and program
WO2014002481A1 (en) 2012-06-26 2014-01-03 Nec Corporation Communication method, information processing apparatus, communication system, communication terminal, and program
WO2014002460A1 (en) 2012-06-26 2014-01-03 Nec Corporation Communication method, communication system, information processing apparatus, communication terminal, and program
US9794170B2 (en) 2012-06-26 2017-10-17 Nec Corporation Communication method, communication system, information processing apparatus, communication terminal, and program
WO2014002455A1 (en) 2012-06-26 2014-01-03 Nec Corporation Communication method, information processing apparatus, communication system, program, node, and communication terminal
US9749240B2 (en) 2012-10-24 2017-08-29 Nec Corporation Communication system, virtual machine server, virtual network management apparatus, network control method, and program
US9930066B2 (en) 2013-02-12 2018-03-27 Nicira, Inc. Infrastructure level LAN security
US9984036B2 (en) 2013-02-26 2018-05-29 Nec Corporation Communication system, control apparatus, communication method, and program
US9838336B2 (en) 2013-03-06 2017-12-05 Nec Corporation Communication system, control apparatus, forwarding node, control method and program
WO2014142094A1 (en) 2013-03-12 2014-09-18 日本電気株式会社 Communication system, physical machine, virtual network management device, and network control method
US9894017B2 (en) 2013-03-12 2018-02-13 Nec Corporation Communication system, physical machine, virtual network management apparatus, and network control method
US9686192B2 (en) 2013-06-28 2017-06-20 Niciria, Inc. Network service slotting
US9952885B2 (en) 2013-08-14 2018-04-24 Nicira, Inc. Generation of configuration files for a DHCP module executing within a virtualized container
US9887960B2 (en) 2013-08-14 2018-02-06 Nicira, Inc. Providing services for logical networks
US10027605B2 (en) 2013-08-26 2018-07-17 Vmware, Inc. Traffic and load aware dynamic queue management
US9531676B2 (en) 2013-08-26 2016-12-27 Nicira, Inc. Proxy methods for suppressing broadcast traffic in a network
US9571426B2 (en) 2013-08-26 2017-02-14 Vmware, Inc. Traffic and load aware dynamic queue management
US9843540B2 (en) 2013-08-26 2017-12-12 Vmware, Inc. Traffic and load aware dynamic queue management
US9548965B2 (en) 2013-08-26 2017-01-17 Nicira, Inc. Proxy methods for suppressing broadcast traffic in a network
US10003534B2 (en) 2013-09-04 2018-06-19 Nicira, Inc. Multiple active L3 gateways for logical networks
US9577845B2 (en) 2013-09-04 2017-02-21 Nicira, Inc. Multiple active L3 gateways for logical networks
US10389634B2 (en) 2013-09-04 2019-08-20 Nicira, Inc. Multiple active L3 gateways for logical networks
US9503371B2 (en) 2013-09-04 2016-11-22 Nicira, Inc. High availability L3 gateways for logical networks
US10033693B2 (en) 2013-10-01 2018-07-24 Nicira, Inc. Distributed identity-based firewalls
US10153965B2 (en) 2013-10-04 2018-12-11 Nicira, Inc. Database protocol for exchanging forwarding state with hardware switches
US9455901B2 (en) 2013-10-04 2016-09-27 Nicira, Inc. Managing software and hardware forwarding elements to define virtual networks
US9699070B2 (en) 2013-10-04 2017-07-04 Nicira, Inc. Database protocol for exchanging forwarding state with hardware switches
US10063458B2 (en) 2013-10-13 2018-08-28 Nicira, Inc. Asymmetric connection with external networks
US9785455B2 (en) 2013-10-13 2017-10-10 Nicira, Inc. Logical router
US9910686B2 (en) 2013-10-13 2018-03-06 Nicira, Inc. Bridging between network segments with a logical router
US9575782B2 (en) 2013-10-13 2017-02-21 Nicira, Inc. ARP for logical router
US9977685B2 (en) 2013-10-13 2018-05-22 Nicira, Inc. Configuration of logical router
US9998530B2 (en) 2013-10-15 2018-06-12 Nicira, Inc. Distributed global load-balancing system for software-defined data centers
CN105830402A (en) * 2013-12-19 2016-08-03 日本电气株式会社 Packet transfer system, controller, and method and program for controlling relay device
CN105830402B (en) * 2013-12-19 2019-10-15 日本电气株式会社 The control method and program of packet forwarding system, control device and trunking
WO2015093561A1 (en) 2013-12-19 2015-06-25 日本電気株式会社 Packet transfer system, controller, and method and program for controlling relay device
US9215213B2 (en) 2014-02-20 2015-12-15 Nicira, Inc. Method and apparatus for distributing firewall rules
US10264021B2 (en) 2014-02-20 2019-04-16 Nicira, Inc. Method and apparatus for distributing firewall rules
US9215214B2 (en) 2014-02-20 2015-12-15 Nicira, Inc. Provisioning firewall rules on a firewall enforcing device
US9276904B2 (en) 2014-02-20 2016-03-01 Nicira, Inc. Specifying point of enforcement in a firewall rule
JP2017506462A (en) * 2014-02-24 2017-03-02 レベル スリー コミュニケーションズ,エルエルシー Control device detection in networks with separate control and forwarding devices
US10164881B2 (en) 2014-03-14 2018-12-25 Nicira, Inc. Route advertisement by managed gateways
US9225597B2 (en) 2014-03-14 2015-12-29 Nicira, Inc. Managed gateways peering with external router to attract ingress packets
US9590901B2 (en) 2014-03-14 2017-03-07 Nicira, Inc. Route advertisement by managed gateways
US9419855B2 (en) 2014-03-14 2016-08-16 Nicira, Inc. Static routes for logical routers
US9313129B2 (en) 2014-03-14 2016-04-12 Nicira, Inc. Logical router processing by network controller
US10110431B2 (en) 2014-03-14 2018-10-23 Nicira, Inc. Logical router processing by network controller
US9647883B2 (en) 2014-03-21 2017-05-09 Nicria, Inc. Multiple levels of logical routers
US10411955B2 (en) 2014-03-21 2019-09-10 Nicira, Inc. Multiple levels of logical routers
US9503321B2 (en) 2014-03-21 2016-11-22 Nicira, Inc. Dynamic routing for logical routers
US9825854B2 (en) 2014-03-27 2017-11-21 Nicira, Inc. Host architecture for efficient cloud service access
US9893988B2 (en) 2014-03-27 2018-02-13 Nicira, Inc. Address resolution using multiple designated instances of a logical router
US9338091B2 (en) 2014-03-27 2016-05-10 Nicira, Inc. Procedures for efficient cloud service access in a system with multiple tenant logical networks
US9413644B2 (en) 2014-03-27 2016-08-09 Nicira, Inc. Ingress ECMP in virtual distributed routing environment
US9794186B2 (en) 2014-03-27 2017-10-17 Nicira, Inc. Distributed network address translation for efficient cloud service access
US9906494B2 (en) 2014-03-31 2018-02-27 Nicira, Inc. Configuring interactions with a firewall service virtual machine
US9503427B2 (en) 2014-03-31 2016-11-22 Nicira, Inc. Method and apparatus for integrating a service virtual machine
US9215210B2 (en) 2014-03-31 2015-12-15 Nicira, Inc. Migrating firewall connection state for a firewall service virtual machine
US9582308B2 (en) 2014-03-31 2017-02-28 Nicira, Inc. Auto detecting legitimate IP addresses using spoofguard agents
US9729512B2 (en) 2014-06-04 2017-08-08 Nicira, Inc. Use of stateless marking to speed up stateful firewall rule processing
US9825913B2 (en) 2014-06-04 2017-11-21 Nicira, Inc. Use of stateless marking to speed up stateful firewall rule processing
US9792447B2 (en) 2014-06-30 2017-10-17 Nicira, Inc. Method and apparatus for differently encrypting different flows
US9613218B2 (en) 2014-06-30 2017-04-04 Nicira, Inc. Encryption system in a virtualized environment
US9489519B2 (en) 2014-06-30 2016-11-08 Nicira, Inc. Method and apparatus for encrypting data messages after detecting infected VM
US10445509B2 (en) 2014-06-30 2019-10-15 Nicira, Inc. Encryption architecture
CN106576069A (en) * 2014-08-26 2017-04-19 阿尔卡特朗讯 Network system
US10270621B2 (en) 2014-08-26 2019-04-23 Alcatel-Lucent Network system
EP2991302A1 (en) * 2014-08-26 2016-03-02 Alcatel Lucent Network system
WO2016030302A1 (en) * 2014-08-26 2016-03-03 Alcatel Lucent Network system
US10257095B2 (en) 2014-09-30 2019-04-09 Nicira, Inc. Dynamically adjusting load balancing
US10341233B2 (en) 2014-09-30 2019-07-02 Nicira, Inc. Dynamically adjusting a data compute node group
US10020960B2 (en) 2014-09-30 2018-07-10 Nicira, Inc. Virtual distributed bridging
US10129077B2 (en) 2014-09-30 2018-11-13 Nicira, Inc. Configuring and operating a XaaS model in a datacenter
US10250443B2 (en) 2014-09-30 2019-04-02 Nicira, Inc. Using physical location to modify behavior of a distributed virtual network element
US9768980B2 (en) 2014-09-30 2017-09-19 Nicira, Inc. Virtual distributed bridging
US10320679B2 (en) 2014-09-30 2019-06-11 Nicira, Inc. Inline load balancing
US9774537B2 (en) 2014-09-30 2017-09-26 Nicira, Inc. Dynamically adjusting load balancing
US10225137B2 (en) 2014-09-30 2019-03-05 Nicira, Inc. Service node selection by an inline service switch
US10135737B2 (en) 2014-09-30 2018-11-20 Nicira, Inc. Distributed load balancing systems
US9866473B2 (en) 2014-11-14 2018-01-09 Nicira, Inc. Stateful services on stateless clustered edge
US9876714B2 (en) 2014-11-14 2018-01-23 Nicira, Inc. Stateful services on stateless clustered edge
US10044617B2 (en) 2014-11-14 2018-08-07 Nicira, Inc. Stateful services on stateless clustered edge
US9692727B2 (en) 2014-12-02 2017-06-27 Nicira, Inc. Context-aware distributed firewall
US10205703B2 (en) 2014-12-02 2019-02-12 Nicira, Inc. Context-aware distributed firewall
US10079779B2 (en) 2015-01-30 2018-09-18 Nicira, Inc. Implementing logical router uplinks
US10129180B2 (en) 2015-01-30 2018-11-13 Nicira, Inc. Transit logical switch within logical router
US10038628B2 (en) 2015-04-04 2018-07-31 Nicira, Inc. Route server mode for dynamic routing between logical and physical networks
US10411912B2 (en) 2015-04-17 2019-09-10 Nicira, Inc. Managing tunnel endpoints for facilitating creation of logical networks
US10225184B2 (en) 2015-06-30 2019-03-05 Nicira, Inc. Redirecting traffic in a virtual distributed router environment
US10361952B2 (en) 2015-06-30 2019-07-23 Nicira, Inc. Intermediate logical interfaces in a virtual distributed router environment
US10348625B2 (en) 2015-06-30 2019-07-09 Nicira, Inc. Sharing common L2 segment in a virtual distributed router environment
US10230629B2 (en) 2015-08-11 2019-03-12 Nicira, Inc. Static route configuration for logical router
US10129142B2 (en) 2015-08-11 2018-11-13 Nicira, Inc. Route configuration for logical router
US10075363B2 (en) 2015-08-31 2018-09-11 Nicira, Inc. Authorization for advertised routes among logical routers
US10057157B2 (en) 2015-08-31 2018-08-21 Nicira, Inc. Automatically advertising NAT routes between logical routers
US10313186B2 (en) 2015-08-31 2019-06-04 Nicira, Inc. Scalable controller for hardware VTEPS
US10230576B2 (en) 2015-09-30 2019-03-12 Nicira, Inc. Managing administrative statuses of hardware VTEPs
US10263828B2 (en) 2015-09-30 2019-04-16 Nicira, Inc. Preventing concurrent distribution of network data to a hardware switch by multiple controllers
US10447618B2 (en) 2015-09-30 2019-10-15 Nicira, Inc. IP aliases in logical networks with hardware switches
US9998324B2 (en) 2015-09-30 2018-06-12 Nicira, Inc. Logical L3 processing for L2 hardware switches
US10204122B2 (en) 2015-09-30 2019-02-12 Nicira, Inc. Implementing an interface between tuple and message-driven control entities
US10095535B2 (en) 2015-10-31 2018-10-09 Nicira, Inc. Static route types for logical routers
US10250553B2 (en) 2015-11-03 2019-04-02 Nicira, Inc. ARP offloading for managed hardware forwarding elements
US10333849B2 (en) 2016-04-28 2019-06-25 Nicira, Inc. Automatic configuration of logical routers on edge nodes
US10348685B2 (en) 2016-04-29 2019-07-09 Nicira, Inc. Priority allocation for distributed service rules
US10135727B2 (en) 2016-04-29 2018-11-20 Nicira, Inc. Address grouping for distributed service rules
US10091161B2 (en) 2016-04-30 2018-10-02 Nicira, Inc. Assignment of router ID for logical routers
US10182035B2 (en) 2016-06-29 2019-01-15 Nicira, Inc. Implementing logical network security on a hardware switch
US10200343B2 (en) 2016-06-29 2019-02-05 Nicira, Inc. Implementing logical network security on a hardware switch
US10153973B2 (en) 2016-06-29 2018-12-11 Nicira, Inc. Installation of routing tables for logical router in route server mode
US10333983B2 (en) 2016-08-30 2019-06-25 Nicira, Inc. Policy definition and enforcement for a network virtualization platform
US10454758B2 (en) 2016-08-31 2019-10-22 Nicira, Inc. Edge node cluster network redundancy and fast convergence using an underlay anycast VTEP IP
US10341236B2 (en) 2016-09-30 2019-07-02 Nicira, Inc. Anycast edge service gateways
US10193862B2 (en) 2016-11-29 2019-01-29 Vmware, Inc. Security policy analysis based on detecting new network port connections
US10212071B2 (en) 2016-12-21 2019-02-19 Nicira, Inc. Bypassing a load balancer in a return path of network traffic
US10237123B2 (en) 2016-12-21 2019-03-19 Nicira, Inc. Dynamic recovery from a split-brain failure in edge nodes
US10484515B2 (en) 2017-01-30 2019-11-19 Nicira, Inc. Implementing logical metadata proxy servers in logical networks
US10154067B2 (en) 2017-02-10 2018-12-11 Edgewise Networks, Inc. Network application security policy enforcement
US10439985B2 (en) 2017-02-15 2019-10-08 Edgewise Networks, Inc. Network application security policy generation
WO2018152303A1 (en) * 2017-02-15 2018-08-23 Edgewise Networks, Inc. Network application security policy generation
US10348599B2 (en) 2017-11-10 2019-07-09 Edgewise Networks, Inc. Automated load balancer discovery
US10374827B2 (en) 2017-11-14 2019-08-06 Nicira, Inc. Identifier that maps to different networks at different datacenters

Also Published As

Publication number Publication date
US20080189769A1 (en) 2008-08-07

Similar Documents

Publication Publication Date Title
Dhawan et al. SPHINX: Detecting Security Attacks in Software-Defined Networks.
Ahmad et al. Security in software defined networks: A survey
Conti et al. A survey of man in the middle attacks
Andersen et al. Accountable internet protocol (aip)
Giotis et al. Combining OpenFlow and sFlow for an effective and scalable anomaly detection and mitigation mechanism on SDN environments
US8054833B2 (en) Packet mirroring
US8230480B2 (en) Method and apparatus for network security based on device security status
US8010085B2 (en) Traffic redirection in cloud based security services
EP1634175B1 (en) Multilayer access control security system
Scott-Hayward et al. A survey of security in software defined networks
US9455956B2 (en) Load balancing in a network with session information
JP5393686B2 (en) Network operating system for managing and securing a network
Bellovin Distributed firewalls
US20020069356A1 (en) Integrated security gateway apparatus
JP4906504B2 (en) Intelligent integrated network security device
US7360245B1 (en) Method and system for filtering spoofed packets in a network
US8959197B2 (en) Intelligent integrated network security device for high-availability applications
US7873038B2 (en) Packet processing
Davies et al. IPv6 transition/co-existence security considerations
Clark et al. Addressing reality: an architectural response to real-world demands on the evolving internet
US8689316B2 (en) Routing a packet by a device
US9288183B2 (en) Load balancing among a cluster of firewall security devices
US20070022479A1 (en) Network interface and firewall device
US8606898B1 (en) Spread identity communications architecture
Casado et al. SANE: A Protection Architecture for Enterprise Networks.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08728566

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct app. not ent. europ. phase

Ref document number: 08728566

Country of ref document: EP

Kind code of ref document: A1