Network Support for the

Document Sample
Network Support for the Powered By Docstoc
					                      Proposed Network Configuration for the
                  LHC@FNAL Remote Operations Center at Fermilab

                                       P. DeMar

   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

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.