Proposed Network Configuration for the LHC@FNAL Remote Operations Center at Fermilab P. DeMar 5/3/06 I. Overview The networking group at Fermilab and the LHC@FNAL Task Force are jointly investigating the feasibility of providing console access to the CMS controls networks at CERN. In order to provide CERN with sufficient confidence to permit access to the CMS controls networks, a dedicated, well-protected network, separate from the Fermilab campus network, is proposed for the LHC@FNAL Center. Consoles in the operations center would be supported on a dedicated switch/router, and use a different address block than the FNAL campus network. Access into and out of the LHC@FNAL network would be based on a default-deny inbound & outbound ACL configuration, with only the needed exceptions to operate properly. The console systems could be included in Fermilab’s centrally-managed vulnerability scanning, automated patching, and anti-virus protection services. The network connectivity between the LHC@FNAL network and the CMS Controls LAN would be a virtual point-to-point link, based on a secure tunnel technology. It is hoped that such a network configuration could serve as the basis for a trusted access relationship between CERN and the LHC@FNAL Center. II. Network Design The LHC@FNAL network would be based on two principles, a dedicated network for the consoles, and tightly restricted access into and out of that network. The consoles would be connected to a dedicated switch located in the console room area. Only the 16 consoles in the operations center would be attached to the switch. Host access to the switch would be restricted by configuring switch ports for secure mode, based on each console’s MAC address. An invalid MAC address would shut down a switch port. Other systems located in the LHC@FNAL Center would need to use the FNAL general LAN infrastructure (wireless or otherwise) for network connectivity. The LHC@FNAL network would utilize a different network address block than the one used within Fermilab’s general facility network. The network address block would not be advertised to the general internet. The consoles would use only static IP addresses from within that network block. There would only be two connections to the LHC@FNAL network’s switch/router, a local connection with the FNAL campus network, and a wide area connection that would functionally be a point-to-point link to the CMS controls network at CERN. The ACL configuration on both interfaces would be default deny inbound & outbound, with only the exceptions necessary to enable secure access from the LHC@FNAL consoles to the CMS controls LAN. The interface to the FNAL campus network would be restricted to allow only Fermilab’s centrally-managed computer security services to have access to the consoles. In the outbound direction, the consoles access into the Fermilab network would be limited to DNS servers and other essential, centrally-managed network services. Access to mail servers would not be allowed. The WAN interface would be restricted to outbound connections from individual console IP addresses to the appropriate CMS controls network address blocks at CERN, with similar, appropriate access granted in the reverse direction. III. WAN Connectivity The WAN infrastructure used for LHC@FNAL connectivity to CERN would consist of a layer 2 path extending across the ESnet Chicago MAN and the US-LHCnet transAtlantic infrastructure. The layer 2 path could either terminate in an existing border network device managed by CERN, or be extended to the CMS controls network, whichever is preferable to CERN. An authenticated layer 3 tunnel, utilizing an agreed-upon tunnel technology such as IPsec, would be implemented to establish a direct connection between the LHC@FNAL network and the CMS controls network. IV. Security Management Models As proposed, the LHC@FNAL consoles would be subject to Fermilab’s standard security management procedures. This would include vulnerability scanning services, centrally-managed automated patch management service, and anti- virus support services. An alternative security management model would be for these services to be provided from CERN, as part of their locally-provided, computer security services. While this is sub-optimal from the perspective of remote (CERN) security management services being somewhat disjoint from local (LHC@FNAL) system administration services, it is feasible to implement, if it resulted in a stronger trust relationship between the LHC@FNAL Center and CERN.