Patent Application
20100281159
The described technology is directed to the field of computer networking, and, more particularly, to the field of network health.
Network Access Control (NAC) technology provides the ability for a network appliance (such as an Ethernet switch) to enforce network access restrictions based on some administratively-defined access policy. These restrictions could include, for example, limiting the types of protocols, network services, servers, or other network devices that a connected device is permitted to access.
In a typical NAC deployment, the NAC enforcement appliance must make a decision about whether and how to enforce access control based on information the connected devices provide to the NAC enforcement appliance via the network. An example of this might be user-based authentication—the NAC device might only allow full network access if a user of the connecting device has authenticated to the network and has the appropriate access privileges.
DHCP provides a mechanism for network hosts on a network to obtain their IP configuration automatically from a server. Such a server is called a DHCP server, and hosts that use a DHCP server are called DHCP clients. The DHCP clients and DHCP servers communicate with each other via special UDP packets called DHCP packets. Well-defined pieces of data called DHCP options can be included in these DHCP packets. DHCP options are discussed in more detail in “BOOTPC/DHCP options,” RFC Sourcebook, available at http://www.networksorcery.com/enp/protocol/bootp/options.htm and pages linked therefrom, which are hereby all incorporated by reference in their entirety.
The DHCP server may be on the same network as the DHCP clients, or the DHCP server may be on another network, with communication between the DHCP clients and DHCP servers fielded by a DHCP relay agent, which is located on the same network as the DHCP clients and knows how to forward DHCP packets to the DHCP server. Additional details about DHCP are included in “Dynamic Host Configuration Protocol (DHCP),” RFC 2131, Internet Engineering Task Force, available at HTTP://www.ietf.org/rfc/rfc2131.txt, which is hereby incorporated by reference in its entirety.
Microsoft has defined a DHCP option containing information about a network host's software state called an SoH (Statement of Health). A system health agent installed on a host assesses the health state of the host and generates an SoH. This SoH contains information pertinent to the health of a network host, and thus an assessment of risk to other hosts on the same network. Typical information contained in an SoH includes:
Personal Internet Firewall—disabled, enabled, and/or a manifest of options/settings;
Anti-virus—disabled, enabled, or enabled and up-to-date, and/or a manifest of options/settings;
Anti-spyware—disabled, enabled, or enabled and up-to-date, and/or a manifest of options/settings;
OS Automatic Updates—disabled, enabled, or enabled and up-to-date (no outstanding vendor-recommended patches); and
Automatic Login—allowed or disallowed.
The network host sends the DHCP server its SoH data, and the DHCP server responds with an SoHR (Statement of Health Response), which informs the network host which aspects of the SoH it finds acceptable, and if the network host should be allowed to interact normally with other hosts on the same network. In doing so, the DHCP server is also functioning as a policy server, examining the SoH of the client and deciding whether or not is should be allowed on the network. System health agents are discussed in greater detail in [MS-WSH]: Windows Security Health Agent (WSHA) and Windows Security Health Validator (WSHV) Protocol Specification, available via links at http://msdn.microsoft.com/en-us/librarv/cc251347.aspx, which is hereby incorporated by reference in its entirety. Additional details about SoHs are included in [MS-SOH]: Statement of Health for Network Access Protection (NAP) Protocol Specification, available via links at http://msdn.microsoft.com/en-us/librarv/cc246924.aspx, which is hereby incorporated by reference in its entirety. Additional details about incorporating SoHs inside DHCP requests are discussed in [MS-DHCPN]: Dynamic Host Configuration Protocol (DHCP) Extensions for Network Access Protection (NAP), available via links at http://msdn.microsoft.com/en-us/library/cc227316.aspx, which is hereby incorporated by reference in its entirety. The encoding of an SoH and SoHR is discussed in greater detail in “NAP SoH Request and Response,” available at http://msdn.microsoft.com/en-us/library/aa506213.aspx, which is hereby incorporated by reference in its entirety.
Microsoft clients do not send an SoH in every request. Instead they look at the responses from a DHCP server to see if they contain an attribute that indicates the server can process SoH payloads. If this attribute is seen by the client, it will resend its DHCP request with the SoH present.
The inventors have recognized that the conventional scheme for managing network health in a DHCP server has significant disadvantages. For example, in some networks, the DHCP server in use is incapable of acting as a health policy server, and is not even able to recognize SoHs. In some networks, the DHCP server in use recognizes SoHs and acts as a health policy server, but in a manner that is not optimal. For example, some DHCP servers are limited in one or more of the following ways: their flexibility for establishing network health policies; their user interface for managing network health policies; their ability to appropriately deliver network health deficiencies and other network health information; and their ability to store and process network health information persistently and reliably.
Accordingly, a software and/or hardware facility is described for intercepting network traffic containing network health information in a node of other than the node to which it is directed by system health agents, and performing health policy server responsibilities on the basis of the intercepted traffic (“the facility”). This interception obviates any need for the system health agents or other aspects of the hosts sending health information to be specifically configured to operate in connection with the facility.
In some embodiments, a health inspection and enforcement node is established in the network for intercepting network traffic containing network health information. In some embodiments, the health inspection and enforcement node is positioned between the DHCP server and the other hosts in the network in order to facilitate this interception.
In various embodiments, the health inspection and enforcement node: modifies DHCP responses produced by the DHCP server to suggest to the hosts that receive them that the DHCP server is capable of processing SoHs; for each DHCP request containing a SoH, extracts the SoH, uses the extracted SoH to make network health policy decisions for the sending host, and forwards the DHCP request to the DHCP server without the SoH; and, for each DHCP response to a host for which a network health policy decision has been made, adding to the DHCP response a SoHR reflecting the network health policy decision made for the host.
In some embodiments, the facility maintains a state for each host that includes a “flow” representing the interactions between the host and the DHCP server, and that includes or is connected to a health assessment and/or a health policy decision for the host.
By performing in some or all of these ways, the facility enables a network node other than the network node to which network health information is directed to act as a health policy server for the network.
The computing device on which the facility is implemented may include input device (e.g., keyboard and pointing device), output device (e.g., display device), and storage device (e.g., disk drives, flash drives). The memory and storage device are computer-readable media that may be encoded with computer-executable instructions that implement the facility, which means a computer-readable medium that contains the instructions. In addition, the instructions, data structures, and message structures may be stored in a data storage medium or transmitted via a data transmission medium, such as a signal on a communications link, and may be encrypted. Various communications links may be used, such as the Internet, a personal area network, a local area network, a wide area network, a point-to-point dial-up connection, a cell phone network, and so on.
Embodiments of the facility may be implemented in and used with various operating environments that include personal computers, server computers, handheld or laptop device, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, digital cameras, network PCs, minicomputers, mainframe computers, computing environments that include any of the above systems or device, and so on.
The facility may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other hosts. Generally, program modules include routines, programs, objects, components, data structures, and so on that perform particular tasks or implement particular abstract data types when executed by a processor. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.
In step 402, the facility uses the contents of the intercepted DHCP packet to create or update a flow reflecting the health state of the host to which the intercepted DHCP packet relates, that is, the host from which an intercepted DHCP request was sent or to which an intercepted DHCP response was sent. Step 402 involves parsing the NAP option 220 in vendor option 43 in the packet. Where the option 220 includes an SoH, option 220 includes a System Health Agent ID type that specifies the organization of the statement of health contained by option 220. The facility parses DHCP options as follows:
An array of 253 elements is created, numbered 1 to 254. Each element may contain NULL (no data), or anywhere between 0 and 65535 bytes of data. The DHCP option number corresponds to the array index. Options 0 (pad) and 255 (end) have special meaning and are not stored. It is important to note a difference between NULL and 0 bytes. NULL indicates the option is not present. If data of 0 bytes is stored, this indicates the option is present, but has a length of 0, therefore containing no data.
The DHCP options field is scanned (starting at byte offset 4 if the DHCP magic cookie is detected). If option 255 (end) is encountered, processing moves to the next step. If option 0 (pad) is encountered, that byte is ignored and scanning resumes as the next byte. In addition to encountering the end option, scanning also stops once the end of the packet (according to length) is encountered. For each option encountered other than 0, 250 or 255, data of the length indicated is copied and stored in the array at the proper index. If data is already present in the array at that index, it is appended. If option 250 is encountered, data is appended to the previous non-250 option's data and the fact option 250 was encountered is stored. If option 250 is encountered before any other options, its data is ignored.
If the DHCP overload option indicates the sname or file fields are used, the previous step is repeated for these fields. Data from a single instance of an option can not span multiple fields, which simplifies the algorithm to be re-applied to arbitrary fields of data. Just like parsing the main option data, if data is parsed in the overloaded fields, processing stops if option 255 (end) is encountered, or the end of the field. If both file and sname fields are overloaded, the file field is parsed before sname. If option 250 is encountered while processing data from an overloaded field, data from the last non-250 option is appended to even if it was not first encountered in the overloaded field.
The order in which individual options are first encountered is stored.
In step 403, the facility draws any possible conclusions about the host from the health state reflected by the updated flow, and acts on these conclusions with respect to the host. In step 404, the facility generates a modified DHCP packet, such as a modified DHCP request from which health information is removed, or a modified DHCP response, to which health information is added. Step 404 involves rewriting the intercepted packet as follows:
Using the stored order, options are written out to the options field. Options having a length of 0 are treated as it they are not present and are not written. If the message is not BOOTP, the DHCP message type option is always written first, followed by the overload option, if present. Writing to the options field stops once the maximum space has been taken, or there are no more options left to write. The maximum space in the options field is determined by the maximum transmission unit size of the network interface (MTU) being used to send the packet, or, if present, the maximum message size specified in the original DHCP message if it is smaller than what is allowed by the MTU.
If the space available in the options field is not sufficient to write all options and the message is not BOOTP, the DHCP overload option is written and indicates either file or both file and sname fields are to be overloaded. The algorithm used could overload only sname and not the file field, but this complicates the implementation with no reasonable benefit. If either file or sname contents are present but their fields are overloaded, their DHCP option equivalents are inserted instead before continuing to process the list of options. Option 255 (end) is always written at the end of a set of options within an overloaded field. If all option data is used and there are still options left to be written, then they are discarded. Partial option data is never written; if the entire option will not fit, it is not included at all.
In step 405, the facility forwards the modified DHCP packet generated in step 404 to the addressee of the intercepted DHCP packet. After step 405, the steps continue in step 401 to intercept the next DHCP packet.
Those skilled in the art will appreciate that the steps shown in
Tables 1-8 below portray an example of interactions between a host, the health inspection and enforcement node, and the DHCP server. Tables 1-4 show, respectively, a first DHCP request sent by the host that does not include a statement of health; the first DHCP request as modified by the health inspection and enforcement node; a first DHCP response sent by the DHCP server in response to receiving the modified first DHCP request; and a version of the first DHCP response modified by the health inspection and enforcement node. Tables 5-8 show, respectively, a second DHCP request sent by the host that does include a statement of health; the second DHCP request as modified by the health inspection and enforcement node; a second DHCP response sent by the DHCP server in response to receiving the modified second DHCP request; and a version of the second DHCP response modified by the health inspection and enforcement node.
First, the host sends the DHCP request packet shown below in Table 1, addressing it to the router that is serving as the DHCP Server for the network.
Option 43 in line 16 contains Microsoft NAP option 220, whose value is one byte of value ‘0’. This indicates that the host is capable of sending SoH data.
In response to receiving the first DHCP request package shown in Table 1, the facility establishes the flow shown in
While
In addition to storing the flow shown in
It can be seen that the modified first DHCP request packet shown in Table 2 is a copy of the first DHCP request packet shown in Table 1, but without line 16 of Table 1 containing the NAP vendor option. If options other than 220 were contained in option 43, then option 43 would be present in this packet with those other options still intact. Since the SoH option 220 is the only option contained by option 43, option 43 is removed completely.
In response to receiving the modified first DHCP request packet shown in Table 2, the DHCP server replies with a first DHCP response assigning a dynamic address to the host. The first DHCP response is shown below in Table 3.
The dynamic address assigned to the host is shown in line 3 of Table 3. In response to receiving the first DHCP response shown in Table 3, the facility matches the first DHCP response to the flow shown in
It can be seen that, in the modified first DHCP response shown in Table 4, option 43 contains Microsoft NAP option 220, whose value is three bytes containing the ASCII values for ‘NAP,’ indicating to the host that it should include SoHs in future DHCP requests.
At a later time, the host sends a second DHCP request shown below in Table 5.
The second DHCP request shown in Table 5 contains a statement of health for the host in line 16, inside option 220, which is in turn inside option 43. In response to receiving the second DHCP request shown in Table 5, the facility updates its flow for this host, performs a health policy determination for this host, and forwards a modified version of the DHCP request to the DHCP server.
The facility further generates a modified DHCP request by reformulating vendor option 43 contained in lines 16-17 of Table 5 to exclude the statement of health data that is inside option 220, which is in turn inside option 43.
Despite RFC 3396, Microsoft uses a proprietary option 250 (“Continue”) to encode oversized options. There is an expired standards draft for this option. The facility is prepared to handle oversized options using either form, and will retransmit or answer using the method originated by the peer. The complete contents of option 43 is found by concatenating option 43 with option 250.
This example also shows option 43 being too big to fit in a standard DHCP option limited to 255 bytes. It is also important to point out the Microsoft option 220 is a vendor option inside option 43, so to decode the oversized data, the facility first reassembles option 43, and uses that data to reassemble option 220. Simply concatenating the raw data from option 43 and option 250 will not produce an intact option 220.
Accordingly, the facility arrives at the modified second DHCP request shown below in Table 6.
In response to receiving the modified second DHCP request, the DHCP server replies with a second DHCP response shown below in Table 7.
In response to receiving the second DHCP response in the health inspection and enforcement node, the facility matches the second DHCP response to the flow for the host shown in
When the host receives this modified second DHCP response, the SoHR that it contains is passed to the system health agent on the host for use in enforcing the network health determination contained in the SoHR.
In various embodiments, the facility uses various approaches to enforce its network health determination for a host. This can involve invoking the assistance of other enforcement entities in the network. This can involve modifying other areas of the DHCP response before forwarding it to the host, including setting a very short lease time (overriding what the server sets in its response); or putting the client on a different IP subnet; or giving the client an alternate default gateway (such as one that applies more strict Internet-access rules); etc.
Each time the host is changed in a way that affects the health system agent's health assessment of the host, the health system agent causes a new DHCP request to be sent containing a new SoH for the host. When the new SoH is received in the health inspection and enforcement node, it is evaluated in accordance with the then-current network health policy and a new network health determination is made for the node. Any changes in this new network health determination for the node are reflected in the health enforcement measured with respect to the node, both those that are performed by the health system agent based upon instructions in SoHRs received by the health system agent and by other enforcement measures. Therefore, if the health attributed values in the earlier statement of health that were the basis for health enforcement against the host are remedied in the health attribute values in the new statement of health, the rights of the host are expanded to reflect this new level of healthiness.
In some embodiments, the facility provides a configuration switch that may be used by an administrator to disable the interception of DHCP packets by the facility and its modification of these packets.
It will be appreciated by those skilled in the art that the above-described facility may be straightforwardly adapted or extended in various ways. For example, the facility can be straightforwardly adapted to intercept datagrams of various types other than DHCP packets to extract and/or insert health information. While the foregoing description makes reference to particular embodiments, the scope of the invention is defined solely by the claims that follow and the elements recited therein.
This application claims priority to and incorporates by reference in its entirety U.S. Provisional Patent Application No. 61/165,423, entitled “Transparent Manipulation of DHCP Packets Containing SoH Data to Enforce Network Health Policies,” filed on Mar. 31, 2009. This application is related to the following applications, each of which is hereby incorporated by reference in its entirety: U.S. Provisional Patent Application No. 61/165,445, entitled “Using In-the-Cloud Storage for Computer Health Data,” filed on Mar. 31, 2009; U.S. patent application Ser. No. ______ (patent counsel's docket no. 65985-8001US01), entitled “Using In-the-Cloud Storage for Computer Health Data,” filed concurrently herewith; U.S. Provisional Patent Application No. 61/165,438, entitled “Network-Assisted Health Reporting Activation,” filed on Mar. 31, 2009; and U.S. patent application Ser. No. ______ (patent counsel's docket no. 65985-8006US01), entitled “Network-Assisted Health Reporting Activation,” filed concurrently herewith.
| Number | Date | Country | |
|---|---|---|---|
| 61165423 | Mar 2009 | US | |
| 61165445 | Mar 2009 | US | |
| 61165438 | Mar 2009 | US |
