1. Introduction
1.1 This policy describes requirements, procedures and limitations for the following:
- maintaining the operational integrity of Penn's central networking and communication systems,
- isolation or disconnection of devices threatening operation or security,
- use of Penn's IP address space,
- switches, wallplates and network wiring,
- university telephone numbers,
- devices on PennNet,
- routing on PennNet,
- DHCP & BOOTP services on PennNet,
- private remote access services connecting to PennNet,
- domains within the upenn.edu domain name space.
2. Purpose
2.1 The goal of this policy is to protect the academic missions served by Penn's computers and networks from disruption.
3. Scope
3.1 This policy is governed by the scope contained in the IT Policy Governance Policy Scope Section and as further modified within a section or statement.
4. Risk To Non-Compliance
4.1 Failure to comply with these networking policy requirements jeopardizes the University mission dependent on central networking services.
5. Requirements
5.1.1.1 This section only applies to computers and devices attached directly, indirectly, or logically to Penn's Networks (PennNet and Wireless at Penn), including improper or defective connections, and private Local Area Networks with active networking components connected to Penn's Network's wallplates and hosts.
5.1.1.2 Information Systems and Computing (ISC) will disconnect from Penn's Network any devices that are improperly connected or have actually damaged or pose an imminent threat of harm to the integrity of Penn's Networks.
5.1.1.3 This section does not address removing computers from Penn's Networks for reasons related solely to their content.
5.1.1.4 If in the judgment of ISC criteria are met which suggest that a system poses a significant and immediate threat to either the security of other Penn devices and networks, or the continued operation of Penn's Networks and devices, and the problem cannot be resolved expeditiously through collaboration between the device owners and ISC, then ISC will notify senior management of the department or unit and will require the owners to remove the device from the network until the problem is solved.
5.1.1.5 If ISC is unable, using the IPAM database, to identify a system owner or Local Support Provider (LSP), ISC will move unilaterally to protect the network by disconnecting the threatening system.
5.1.1.6 In cases where there is a persistent disagreement between ISC and the owner of the perceived threat, ISC must notify the owner and the LSP of the following information in writing:
- The reason for the disconnection
- What steps must be taken for the network connection to be restored
- How to arrange for the system to be reconnected
- The process of appealing a decision to disconnect
5.1.1.7 When the owner of the system has taken the steps necessary to correct the problem, ISC will restore the PennNet connection as soon as possible.
5.1.1.8 Appealing a Decision to Disconnect: The Penn Chief Technology Officer (CTO) shall appoint a subcommittee to review appeals of decisions to disconnect computers. The subcommittee will consist of:
- At least four members of the IT Policy Committee, one of whom to serve as chair,
- Penn CTO or her/his designate,
- University Information Security Officer or her/his designate.
5.2.1.1 This section specifies the requirements for installation of new wiring or the relocation of existing wiring as it pertains to PennNet, Telephone, or PVN networks. In this policy, "network wiring" will be represented as copper or fiber optic cables or trunks installed in all networks and includes pathways or conduits that ISC Technology Services owns and manages for the University of Pennsylvania.
5.2.1.2 This section covers all network wiring that runs from PennNet wiring closets and gets terminated onto PennNet wall plates, fiber optic cabling, pathway, and conduit infrastructure that is installed, terminated, owned, and managed by ISC Technology Services.
5.2.1.3 ISC Technology Services is the department that manages the installation and certification of all PennNet network wiring on campus. Individual departments must not manage or install their own network wiring.
5.2.1.4 All network wiring contractors must be certified by ISC Technology Services before they can perform any installation or repair work on campus.
5.2.1.5 Non-ISC installed wiring that may exist in campus locations must be certified and approved by ISC Technology Services before it shall be connected to the PennNet network.
5.2.1.6 ISC Technology Services must be contacted and give its approval before any PennNet network wiring may be altered, removed, or relocated as part of University construction projects. In this instance, the network wiring should be identified by its PennNet wallplate ID, and the appropriate services must be disconnected before removal or temporary relocation work can begin. All wiring must be recertified before any network services can be restored. Note that network wiring that must be removed as part of construction or demolition, should be completely removed starting from the demarcation point of the network, and along the entire pathway back to the wiring closet, as per the NFPA NEC Code.
5.2.1.7 ISC Technology Services must approve the use of any of its wiring pathway or conduit systems by any department or outside the organization.
5.2.2.1 Information Systems and Computing is responsible for the operation of Penn's data networks (PennNet) as well as the establishment of information security policies, guidelines, and standards. It, therefore, has the authority and responsibility to specify requirements for access to PennNet.
5.2.2.2 This policy describes the circumstances under which PennNet wall plates (jacks) may be considered unused and the process by which they can be disabled and deactivated in an effort to reduce operational costs and improve the security of PennNet in a programmatic way.
5.2.2.3 The purpose of this policy is to ensure that ISC is making the best use of capital assets such as switches and router interfaces that are necessary to support active wall plates.
5.2.2.4 This section applies to all PennNet wall plates associated with switches managed by ISC with the exception of switch ports associated with ISC-managed or customer-managed data centers.
5.2.2.5 Switch ports that have not had a network link detected for 45 or more calendar days (according to ISC's current network management and reporting tools) will be considered unused and may be disabled.
5.2.2.6 Switch ports that have not had a network link detected for 45 or more calendar days (according to ISC's current network management and reporting tools) will be considered unused and may be disabled.
5.2.2.7 Campus IT staff will receive notification from ISC at least 10 business days prior to the unused port analysis process being run.
5.2.2.8 Individual ports can be identified in advance to ISC Client Care via a ticket and the exclusion will be noted in the configuration. This port will be exempt until a client asks for it to be removed.
5.2.2.9 Blanket exemptions for large areas of a campus building may be requested by a local school/center IT Director. To cover all of these ports, ISC may elect to exclude all ports wired to a single wiring closet.
5.2.2.10 While the switch port remains in a disabled state, a customer may report a dead port to ISC Client Care and it will be re-enabled at no charge within the same timeframe as a standard activation request.
5.2.2.11 Switch ports that are in a disabled state for an additional 10 business days will be scheduled for deactivation.
5.2.3.1 The purpose of this policy is to specify the requirements and limitations for wireless LAN operation on PennNet. While wireless LANs can provide a very efficient and convenient way to maintain access and provide some limited user mobility, their use under certain circumstances can cause significant problems.
5.2.3.2 This section applies to any device acting as a 802.11 access point on PennNet and/or in any University of Pennsylvania campus building or open area.
5.2.3.3 Any individual wishing to set up a new wireless LAN must first determine if wireless service already exists in the area to be covered. The interoperability of the intended installation and any existing wireless infrastructure must be addressed among the affected groups. ISC Technology Services reserves the right to disallow the operation of an AP if it would result in a conflict with another AP or networking device serving the same area.
5.2.3.4 ISC Technology Services is authorized to coordinate reconfiguration, disconnection, or removal of rogue (unauthorized) wireless access points.
5.3.1.1 The purpose of this policy is to specify the IP address registration requirements for all devices attached to PennNet.
5.3.1.2 This section applies to all devices configured with PennNet IP addresses including non-globally routable IP addresses.
5.3.1.3 This section applies equally to devices that have static IP address configuration and to devices which may acquire addresses dynamically such as through the Dynamic Host Configuration Protocol (DHCP) or similar means. This policy also applies to devices that may connect using a Network Address Translation (NAT) service.
5.3.1.4 Every network interface configured with one or more IPv4 addresses, including addresses from the non-globally routable ranges, must have corresponding entries for all of these IPv4 addresses in the IP Address Management (IPAM) database.
5.3.1.5 Network-connected devices that have IP configurations must not use IP addresses already registered in the IPAM database for other devices.
5.3.1.6 IPv6 address configured using a method other than SLAAC (such as static configurations or DHCPv6) must be registered in the IPAM database.
5.3.2.1 The purpose of this section is to specify domain naming requirements and limitations that will provide a scalable solution to domain name requests, promote effective use of a valuable resource, and protect the reputation of the University and its many brands. This section will enable Penn’s responsibility centers (schools and major administrative departments), and university-wide computing services to have global and local name identity. It will facilitate the use of domain names as a tool to share and discover information and resources as easily and unambiguously as possible. This section will also allow for the delegation of authority of these domain-naming conventions to the Schools and Centers at the University. While it may seem reasonable to grant the creation of any domain name upon request, a structured approach to domain naming conventions will provide a less ambiguous solution in reducing duplicate requests and/or contention of domain names. Additionally, the turnaround time for domain names will be expedited due to this process of standardization.
5.3.2.2 This section covers any requests for new third-level domain names that fall within the upenn.edu domain name space.
5.3.2.3 The assignee of a third-level domain name may create DNS resource records within that third-level domain name space of any type that is supported by the central DNS infrastructure servers and their management interfaces. Requests for such DNS records, or for delegated access to manage DNS records directly, must come from a department head or his/her designee. Examples: An organization assigned the domain name example.upenn.edu may create A, AAAA, MX, or other DNS resource records owned by example.upenn.edu, and may also create records for subdomains of example.upenn.edu (such as host.example.upenn.edu or host.department.example.upenn.edu).
5.3.2.4 If a domain name request is not otherwise permitted by these statements of policy, a third-level domain name cannot be assigned, and a fourth-level or higher domain name must be used instead.
5.3.2.5.1 Center Name: A center of the University of Pennsylvania will be assigned one third-level domain name in the form of the full center name or an abbreviated version of the center name--i.e. centername.upenn.edu. Example: publicsafety.upenn.edu or hr.upenn.edu
5.3.2.5.2 School Name: A school of the University of Pennsylvania will be assigned one third-level domain name in the form of the full school name or an abbreviated version of the school name--i.e. schoolname.upenn.edu. Example: nursing.upenn.edu, sas.upenn.edu, med.upenn.edu, vet.upenn.edu
5.3.2.5.3 University-wide information resource: A university-wide information resource will be assigned a third-level domain name according to the name of the service it provides, the function it performs, the subject about which it aims to share information or services, or an unambiguously abbreviated version thereof. Valid university-wide information resources are those that are available for use by faculty, staff, and/or students of all schools and centers, as well as those that are clearly recognizable as university information resources from outside of the university community. Examples: directory.upenn.edu, workday.upenn.edu, www.upenn.edu, router.upenn.edu, commencement.upenn.edu, coronavirus.upenn.edu
5.3.2.5.4 Institutes: An Institute of the University of Pennsylvania will be assigned one third-level domain name in the form of the full Institute name, or an abbreviated version of that name--i.e. institutename.upenn.edu. Example: ircs.upenn.edu (Institute for Research in Cognitive Science)
5.3.2.5.5 Joint Research Projects: A joint research project of the University of Pennsylvania will be assigned one third-level domain name in the form of the full project name, or an abbreviated version of the project name--i.e. jointresearchprojectname.upenn.edu. The project must be approved by the school's head or designee. Applications for a domain name must include the description of the program, the full program name, a list of the participating schools and/or universities, and the details regarding how the domain is to be used. Example: cml.upenn.edu (Cardiographic Modeling Lab?Joint Project between GSFA and School of Social Work)
5.3.2.5.6 Academic departments within Schools: An Academic Department within a school will be assigned one third-level domain name in the form of the full department name, or an abbreviated version of the department name, provided that: the department hosts campus-wide information resources or externally visible services such as email or web; the request is pre-approved by a designee of the main school (typically the school’s IT director); and the requested domain name would not conflict with the name of any other department at the University nor be reasonably expected to cause confusion. Examples of qualifying domain names: math.upenn.edu instead of math.sas.upenn.edu; or cis.upenn.edu instead of cis.seas.upenn.edu. Academic departments that do not qualify for a third-level domain name under this policy must use domain names that fall within the school's assigned third-level domain name space. Fourth level or higher domain names can be assigned directly by the department's Local Support Provider (LSP) or his/her technical designee. Examples of non-qualifying names: finance.upenn.edu instead of finance.wharton.upenn.edu; policy.upenn.edu instead of policy.gse.upenn.edu.
5.3.2.5.7 Departments within Centers: A department within a center will be assigned one third-level domain name in the form of the full department name, or an abbreviated version of the department name, provided that: the department hosts campus-wide information resources or externally visible services such as email or web; the request is pre-approved by a designee of the center (typically the center’s IT director), and the requested domain name would not conflict with the name of any other department at the University nor be reasonably expected to cause confusion. Examples of qualifying domain names: police.upenn.edu instead of police.publicsafety.upenn.edu; or ogc.upenn.edu instead of ocg.president.upenn.edu. Non-academic departments that do not qualify for a third-level domain name under this policy must use domain names that fall within the center's assigned third-level domain name space. Fourth level or higher domain names can be assigned directly by the department's Local Support Provider (LSP) or his/her technical designee. Example of a non-qualifying name: security.upenn.edu instead of security.isc.upenn.edu.
5.3.2.5.8 Student Organizations and Administrative Groups: A student organization or Administrative Group of the University of Pennsylvania will be assigned a fourth level domain name in the form of the student or Administrative organization name, or an abbreviated version of this name. Normally, student organizations depend on central service workstations for their email and web services, and residence networks such as Resnet and Greeknet are serviced dynamically via DHCP. In those cases where domain names are required, a third-level domain name of group.upenn.edu has been created to provide for this hierarchy. Requests for student and administrative domain names should be initially submitted to the office of VPUL. The Office of VPUL will submit any domain name requests. Examples: (ADD Revised Examples HERE). Students may lobby for a school or department to sponsor a third-level domain name. In those cases, the designee of the school or department will be financially and administratively responsible for this domain name. As such, they should submit the domain name request. These requests will be reviewed according to statements of the policy covering departments within schools and centers.
5.3.2.6 The assignee of a third-level domain name under this section is implicitly assigned the corresponding fourth-level domain name in the private.upenn.edu domain name space for the purpose of creating address resource records (“A” type) for non-routable IPv4 addresses (RFC 1918). Address resource records for non-routable IPv4 addresses may not be created in the upenn.edu domain name space except within the private.upenn.edu domain name space. Address resource records for any other type of IP address, including “AAAA” type records for IPv6 addresses, may not be created within the private.upenn.edu domain name space. For example, the assignee of isc.upenn.edu is also assigned isc.private.upenn.edu.
5.3.3.1 This policy specifies the naming requirements for the creation/changing of new/existing names within the @upenn.edu email address space.
5.3.3.2 The purpose of this policy is to provide naming requirements and limitations that will provide a scalable solution to requests for @upenn.edu email addresses. This policy will enable the schools, departments, and university-wide computing services to have global and local name identity. While it may seem reasonable to grant the creation of any @upenn.edu email address request, a structured approach to naming conventions will provide a less ambiguous solution in reducing confusion and/or contention for Penn-wide email addresses. Additionally, the turnaround time for @upenn.edu address requests will be expedited due to this process of standardization.
5.3.3.3 This section covers naming that falls within the @upenn.edu email address space.
5.3.3.4 PennKey@upenn.edu may be assigned only for individuals associated PennKeys.
5.3.3.5 For non-individuals, name@upenn.edu may be assigned if it is descriptive, clear, and unambiguous across Penn (e.g. president@upenn.edu, provost@upenn.edu) unless it is better described in a third-level domain (e.g. dean@seas.upenn.edu). Requesters are urged strongly to consider that the @upenn.edu namespace is finite, and to use addresses within a third-level domain wherever possible (see Recommendations, below).
5.3.3.6 For any other cases, name@upenn.edu may be configured only to auto-respond with a message indicating possible ways to disambiguate the destination address. For example, help@upenn.edu would result in a response indicating addresses for contacting the current sponsors of that reserved name in PennNames.
5.3.3.7 If it falls within the PennNames namespace, the name must be registered in PennNames.
5.3.4.1 This section specifies requirements for the management (installation, change, and disconnection) of telephone numbers in Penn’s telephone exchanges: 215-573, 215-746, 215-898, and 215-417.
5.3.4.2 The purpose of this section is to specify requirements for provisioning and managing telephone numbers in use by the University of Pennsylvania.
5.3.4.3 This section applies to all phone numbers in telephone exchanges 215-573, 215-746, 215-898, and 215-417 and currently owned/assigned to the Trustees of the University of Pennsylvania.
5.3.4.4 Telephone numbers must be provisioned through existing ISC Client Care processes.
5.3.4.5 Porting of telephone numbers is prohibited without prior review and consultation with ISC. Clients shall contact ISC Client Care to request a consultation.
5.3.4.6 Porting of existing Penn-provided telephone numbers must be performed only by ISC.
5.3.4.7 Numbers can only be ported to ISC-approved carriers.
5.4.1.1 This section specifies the requirements for Dynamic Host Configuration Protocol (DHCP) servers and related infrastructure operating on PennNet.
5.4.1.2 The purpose of this section is to specify the requirements and limitations for DHCP server operation on PennNet.
5.4.1.3 This section applies to any device acting as a DHCP service or server acting as a relay agent on PennNet.
5.4.1.4 Restrictions on the operation of servers apply to all centrally operated PennNet subnets. Subnets that are supported by organizations other than the University's central networking organization are not covered directly by this policy. Network users are advised to check with their local LSP if uncertain.
5.4.1.5 ISC Technology Services reserves the right to disallow a server or relay agent if it would result in a conflict with another serving the same broadcast domain.
5.4.1.6 Schools or Centers wishing to run their own DHCP servers should open a ticket with ISC Client Care to coordinate the router configuration to relay DHCP requests to the School or Center's DHCP server.
5.4.1.7 DHCP service offered by ISC Technology Services is restricted to a subset of possible DHCP functionality. Standard DHCP service provided on centrally operated servers includes no special options. Depending on various performance, robustness, and interoperability considerations, ISC Technology Services may be able to provide customized options.
5.4.1.8 All IP addresses handed out by a server must be registered in accordance with the section of the Policy on the use of PennNet IP address space.
5.4.2.1 The purpose of this policy is to identify the circumstances when a routing device may be connected to PennNet. This policy defines the scenarios and procedures for connecting a routing device to PennNet, and in doing so, not adversely affecting the provision of network service to others.
5.4.2.2 This section applies to any device acting as a router that has at least one connection to PennNet and either runs a dynamic routing protocol or static routing, or requires routing configuration changes to the central PennNet routing core. Restrictions on the use of routing devices apply to all networking segments of PennNet.
5.4.2.3 Anyone who wishes to connect a routing device to PennNet must register the device with ISC Technology Services. ISC Technology Services will review the request and reserves the right to disallow a routing device if the proposed setup would conflict with other devices.
5.4.2.4 All network interfaces on routing devices that are configured with one or more IP addresses, including addresses from the non-globally routable ranges, must comply with the section on the use of PennNet IP address space.
5.4.2.5 Dynamic routing protocols can only be run on routing devices that ISC Technology Services manages or on which they have full administrative access ("root" access).
5.4.2.6 Routing devices cannot be connected to more than one point on the PennNet side of the demarcation point as this may have negative service implications on central PennNet routing operation.
5.4.2.7 Links to external networks from outside organizations or commercial providers are not permitted to be connected to any routing devices other than to the PennNet central routing core. Connectivity of these external networks is subject to review and approval by ISC N&T Operations.
5.4.2.8 ISC Technology Services will not be responsible for the operation of the routing/switching device that resides on the customer side of the PennNet demarcation point.
5.4.3.1 ISC Technology Services provides support up to the wallplate only, and therefore will not be responsible for the operation of the switch or any local associated wiring with the LAN(s) unless installed by ISC Technology Services for specific temporary purposes, such as traffic profiling or troubleshooting.
5.4.3.2 Remote network access (i.e. any access other than from the console) to privileged accounts (e.g. root, Administrator) must use Strong Authentication by no later than July 1, 2005.
5.4.3.3 Switches cannot be connected to more than one point on the PennNet side of the demarcation point without approval from ISC Technology Services.
Resources
Status | Date | Approval |
Adopted | 01/01/2022 | ISC CIO - Tom Murphy |