Problem: Current IPAM solution for Shands Healthcare and the University of Florida Health Science Center must be expanded or replaced to meet changing network configuration, security, and reporting needs of Shands and the University of Florida. Final solution may involve either upgrading the design of the largely proprietary system already in place, purchasing a turnkey solution from a commercial vendor, or some combination of the two. The purpose of this paper is to describe our diverse environment accurately with a prioritization of the requirements for an extensible IPAM system. Network Description (Shands and the UF Health Science Center) Shands currently manages over 230 networks of varying sizes between all Shands facilities and the University of Florida Health Science Center (UFHSC). Shands is in the process of migrating off of the eight remaining 18.104.22.168/24 networks that will be returned to the University of Florida. After that point, the enterprise and its customers will be entirely on 159.178/16 and the private networks 10.4/16, and 10.14/16. In addition to the normal data networks, we also provide separate geographically based VLANs for wireless communication and Voice Over IP (VOIP) devices. The UFHSC is an academic health center composed of six health-related colleges (Medicine, Nursing, Pharmacy, Dentistry, Public Health, and Veterinary Medicine) on a single contiguous campus. Information Systems for each of these colleges is further separated into additional distinct, often autonomous, groups. Though closely affiliated with Shands Healthcare and its mission, the reporting, security, and network policies and practices of these UFHSC groups may very significantly from those of Shands. A key example of this is the use of different and non-cooperative authentication and authorization systems for Shands and the UFHSC. The Shands enterprise BIND and DHCP servers are each using ISC (Internet Software Consortium) software. DNS services are provided by a primary nameserver, ns1.shands.ufl.edu, and a secondary slave nameserver, at ns2.shands.ufl.edu. DHCP and BOOTP services are provided by a single server, dhcp.shands.org. The leases and configuration files of this server are copied via rsync to a manual failover server, dhcp2.shands.ufl.edu, every 3 minutes. Should the primary fail, the backup could be renamed and the DHCP server software started w/the last configuration and leases file available (never more than 3minutes old). Although Shands DNS and BOOTP/DHCP services are provided for UFHSC administrators as part of the contractual agreement between the two groups, there is no requirement that individual UFHSC departments must use those services. Dependent on their needs and resources, many groups decide to run their own services, provided they remain good network neighbors, causing no disruption of services for others. Current IPAM environment Networks shared by Shands and the UFHSC are provided name service and roaming DHCP service from separate DNS and DHCP servers. Dynamic DNS (DDNS) is not supported. All devices unknown to the Shands servers are denied network configuration information, so no devices can simply acquire an IP address by connecting to an active network port within Shands or the UFHSC. Authorized Shands and UF department and college administrators request IP addresses for their devices by registering them with Shands via a web-based form. After providing the requisite information for the device, the information is stored in a database and the request fulfilled. If the request is for a static IP address, the information is automatically emailed to the role mailbox, IPAdmin@shands.ufl.edu. Normally, within two business days, the IP administrator will manually assign an IP address for the device and email the address and network information back to the requestor. If the manual address requires BOOTP service, IPAdmin will add it to the Shands BOOTP server as a fixed-address assignment for the given address and restart the DHCP server. If the request is for a dynamically allocated IP address, after a successful submission, the device information is written to an interim registration file. Every 4 minutes, the latest registrations are added to the primary DHCP server configuration and the server restarted. At this point, the device can acquire an IP address on any Shands or UFHSC network managed by Shands. DHCP configurations With few exceptions, parameters passed via DHCP are global and not network or registrant specific. They include: Subnet mask Gateway or router interface Default domain (shands.ufl.edu) DNS servers NetBIOS nameservers SLP Directory Agents SLP Service Scope Cisco VOIP Call Manager Device registration There are essentially three types of device registration request: - static, no BOOTP - static, BOOTP services requested - dynamic, via Shands DHCP LAN administrators in Shands and the UFHSC may request authorization to register devices for their department or group by emailing a request to IPAdmin@shands.ufl.edu. The Shands IP administrator confirms w/the primary technical contact for the department or college to ensure this person has permission to register devices for that group. The list of primary technical contacts is currently maintained at http://www.health.ufl.edu/itcenter/services/compcord.shtml. Authorization information is stored in a local database while authentication is based on the University of Florida’s GataorLink service (LDAP with a Kerberos backend). Using PERL modules developed by the University, user authentication is performed and a session cookie is created on the client’s browser for his connection to the Shands Network Services web pages. After a prescribed period of inactivity (15 minutes), the user is required to reauthenticate to continue using the services. For static assignments, requiring no BOOTP services, the IP administrator simply finds an unused IP address, as marked in the comments field of the network’s reverse zone file, and assigns it to the device. Device registrations must contain the exact physical location (facility, bldg, floor, room) of the device to ensure that the allocation is made from the proper network. Documentation of the registration (dept, location, HW address) is made in the reverse zone file comment field and the assigned IP address is sent to the email address of the registrant, or to the email address of the main technical contact for his department or group. Static allocations requiring BOOTP services, usually for printers or print servers, follow the procedure outlined above for static allocations. After that, a fixed address device stanza is created for them in the DHCP server configuration and the server is restarted. From that point, any broadcasts from that device on that network should receive the allocated IP address. Dynamic allocations require no manual intervention. A receipt email of the registration is sent to the registrant, if possible, and a copy is also sent to IPAdmin. Additionally, a device registration record is created in a separate database. Other DNS / DHCP administration tasks In addition to registering devices for network communication, the Shands Network Services webpage (http://net-services.shands.ufl.edu) provides these tools for authorized network systems administrators: ■ Query device registration and current DHCP address leases for either IP address or HW address. Used to help determine identity of devices and department or group responsible for the device. ■ Query status of DHCP address pools for each network. Will display number of active leases and number of unused addresses remaining to help administrators confirm there are available IP addresses on any network. ■ List DNS resource records (RRs) for any domain for which the Shands nameservers are authoritative. ■ View/search nameserver zone records for comments. Helps admins confirm statically allocated IP addresses belong to their department or group. Requirements and Needs: A consolidated DNS and DHCP IPAM solution that provides - roaming access for dynamically allocated devices - DNS name consistency across networks - multiple management classes for providing different network configuration parameters based on device type and registrant - graphical management system for easy administration and reporting - support for distributed management with varying levels of access and control ■ Infrastructure 1. Secure Dynamic DNS (DDNS) so that devices may maintain the same DNS name regardless of their physical location or IP address. 2. DHCP failover configurations for high availability and redundancy. 3. Native use of Internet Software Consortium (ISC) BIND and DHCP, including capacity for updating the code without vendor intervention 4. Support for BIND views, caching only nameservers, and IPV6. 5. Support for multiple DHCP management classes, and current client options 6. Quick and proactive determination of rogue devices providing unauthorized or incorrectly configured DHCP services ■ Structured device registration system 1. Departmental groups and individual authorization based on UF and Shands Security Units. Specifically, each Unit ISA (Information Security Administrator) would be responsible for delegating authority for other administrators within that Unit. 2. Ability for Unit ISA to set the global parameters to be passed to devices within his/her group as part of a normal DHCP communication (e.g., NETBIOS servers, SLP directory agents, Active Directory configuration, DNS servers, default domain, PXE servers, etc.) 3. Option of authentication sources: i.e., GatorLink, Kerberos, UFAD for UF staff, Shands OID, ShandsAD, Radius for Shands staff 4. Some administrators able to “proxy” register devices for many different groups; one example might be a HealthNet tech registering laptop NICs for students in different colleges. 5. Security administrators given extra authority in order to delete or disable registrations, query lease information, etc. 6. All administrators able to query, edit, and delete the device registrations for the groups for whom they have registration authority. 7. “Age” device registrations. After some period of device inactivity on the network, warn the department administrator and then remove the device from the registration database and server configuration. 8. An exception list of HW addresses that would be checked before a successful registration is completed. If the device being registered is on this list, the registration would be denied. Examples of devices that might be placed on this list would include stolen devices, incorrectly configured or insecure devices. 9. Fields and attributes required for device registration: - Registration expiration (remove device after expiry date; if empty, don’t remove) - Unit or group responsible for the device (an administrator may be authorized to register devices for several groups) - Requested DNS name (if DDNS, only) - Allocation type (static, static w/BOOTP, dynamic) - Hardware address - Client name - Device type - Device operating system - Name of primary user or group - Serial number of device - Other comments ■ Reporting and Analysis 1. Ability to query device registrations and address leases, real-time and historically. 2. Ability to trend static and dynamic address use and alert when address pools are reaching a critical threshold. 3. Alert to potential DNS zone and domain resolution issues Questions: (some for us, some for vendor) ■ How to maintain accurate device inventory information? ■ What will be the process to maintain Units and Unit ISAs and ISMs? ■ Can large lists of decommissioned devices be removed or changed as a group? ■ What kind of reporting and trending tools are available? ■ What are our plans for future NAC (Network Access Control)? Where in our environment? Process Examples Device Registration UF Department of Surgery (College of Medicine) receives a new desktop and wants it to receive an IP address dynamically anywhere w/in Shands or the University of Florida Health Center. An administrator for the department, who is also an authorized administrator for Pediatrics, connects to the device registration system and authenticates against the University of Florida LDAP server. After authenticating successfully and choosing to add a device, he is presented w/a screen requesting the following information: HW address Address allocation required (DHCP, static BOOTP, static manually configured) Registration unit (in this case, a pull-down menu allows user to choose between Surgery and Pediatrics to assign the responsibility of this device) Device type (server, desktop, printer, laptop, pda or other portable, clinical device, environmental device, etc) Device location (required for static IP address requests) DNS name required (if static IP address requested) Device description Associated user information, if applicable. If available, a user name or email address. Network zone for device (closed, protected, open) Registration expiration (never, two weeks, four weeks, etc) Upon submission, static IP address requests are emailed to a role-based account for manual allocation. For both static and dynamic address allocation, the device HW address provided is checked against the current database of registered devices. If the device does not already exist, the registration information is added to the database, along with the date of registration, registrant unit (in this case Surgery), and registrant login name. The devices to be configured dynamically via DHCP are added to the vendor class corresponding to the Department of Surgery in the DHCP server. Within the scope of that class, configuration variables (e.g. SLP servers, NTP servers, DNS servers, default domain, etc) unique to Surgery are defined. For each unit, there may be several vendor classes defined within the DHCP server; e.g. Surgery- Mobile-Open, Pediatrics-Fixed-protected. These vendor classes will identify the unit, requested lease period (likely a shorter lease period for mobile devices), and the security zone required for the device. Device Registration Modifications An authorized administrator wishes to move a registered device from an open network zone to a protected (filtered) security zone. After authenticating, he searches his department’s list of registered devices (sorted by HW address or registration date). After selecting the device he wishes to change, the initial registration screen is provided w/all fields modifiable except for the HW address. He makes the necessary change and resubmits the new information. Device database information changed and the device is moved from existing security zone class in DHCP server to new security zone class. Reporting A device was compromised last night and began attacking other network devices. We have an IP address and need to find the identity of the device that had that address at that point in time and turn it off, contacting the responsible department when we do. Statically allocated addresses on a network are almost depleted. Need a trending report on a given DHCP address range to determine the maximum number of addresses used and how use is changing over time, so that we can reclaim addresses for static assignment. A given DHCP address pool becomes 90% utilized. Email alerts (incl to a paging gateway) are sent to the IPAM administrator’s mailbox to notify them that it may be necessary to add more address space to the pool. If devices are no longer active on our networks, we wish to remove them from the database of devices that may acquire IP addresses dynamically. Create a report of all registered devices that have not acquired an address lease w/in the last six months. Changes are made to an existing registered device. A record of the change, incl the date and the registrant making the change, is emailed to the unit’s primary administrator (ISM) and the registrant. Delegated Authority and Roles The role of central IPAM administrator creates one administrator for each registrant group (corresponds to the security manager, or ISM, already formally defined w/in the University of Florida computer environment). This ISM can define DHCP allocated parameters for all devices acquiring IP addresses dynamically. Each ISM creates users capable of adding, deleting, modifying, querying device registrations for his or her unit only (e.g., Surgery, Pediatrics, etc). Do not have the ability to change the group’s defined DHCP allocated parameters. Security administrators for either Shands or the UFHSC have the ability to query, remove, or edit devices for any unit or group w/in the enterprise. IP “guest” users have the capability to perform certain non-device specific queries and reports.
Pages to are hidden for
"IPAM Technical Specifications"Please download to view full document