General requirements:

  1. Only ITSO approved, locked down, end user computers are allowed to connect to the RLAN

  2. Separate VPN, from general university VPN, with a separate authorization process for RLAN access

    1. Only use laptops sanctioned by ITSO

    2. Laptops can only use VT certificates generated by ITSO

    3. Laptops must be brought in on a regular, scheduled basis for updates

  3. IPv6 compliant hardware. IPv4 still needed because users access IPv4 only services from the RLAN

  4. RLAN phase 2 will continue to support open outbound traffic from the RLAN and collect traffic analytics towards development of a whitelist

  5. Standard maintenance window of 3-7am Tuesday's and Thursday's, any maintenance outside this window must be announced using the VT-DNET LISTSERV

  6. ITSO monitors inbound and outbound traffic SPAN on each side of the ASA

  7. Create a DNS server, with blacklist, inside the RLAN

  8. Test instance of RLAN uses formal test range (top 8 or 16 addresses) for each RLAN subnet/vlan for testing

  9. Establish a LISTERV for general RLAN support

  10. "Big Fix" software required for all hosts connected to the RLAN

  11. Require 802.1x (Network access control protocol)

  12. Using Host Based Enforcement to validate patch level and quarantine or sand-box the host until compliant

  13. Enforce encryption at rest according to the "Standard for Storing and Transmitting Personally Identifying Information"

  14. Secure mechanisms for data import and export on the RLAN

Possible Central IT Services to Include Inside the RLAN

  1. DNS

    1. One more thing to consider.  Eric is working on what we are calling a Network Services Area VPN (in the MPLS sense) that will be directly reachable in all VPNs.   DNS/NTP/DHCP will all be available there. I do not know if it would be appropriate for services like AD.

    2. Another variable is if the DNS service in rLAN would be the same as our campus service or if it is going to do RPF or something different.

    3. Once NAT moves to the edge of campus (I am assuming rLAN NAT will move there but there will still be a firewall between rLAN and campus) some config may be simplified.

  2. NTP

  3. DHCP (Only static IP configurations as of now inside RLAN)

  4. Active Directory Services (Hokies ID)

  5. Enterprise Directory Services (PID)

  6. Network Directory Services (Network ID)

  7. Banner (INB, others?)

  8. Patching (BigFix relay is already inside RLAN)

    1. Consider moving the BigFIX box to a separate DMZ-like area. That area could reside in either the RLAN or the Central IT services area.
    2. Some areas may need or want very restrictive settings while others may only need a few. With that in mind, we could consider the RLAN the base restriction, define it in general and then step back and allow local departments to decide for themselves what restrictions to add on top of that. Steve Huff is a good example of this now.

  9. Storage & Backup Services

  10. Application Proxy (new additional service)

  11. Email (Maybe reduced functionality email of some sort... text only, no attachments?)

Possible Approaches (see diagram):

  1. Do nothing. If a service can be made to work inside the RLAN by adding firewall exceptions, then leave the service outside the RLAN and add exceptions on the network firewall and the host firewall. This is basically what we do now.

    1. ProsCons
      1) Inexpensive                                                                                                                1) Added complexity
      2) Simple and easy2) Less functionality (no DHCP inside RLAN)
      3) Requires no additional service instances inside the RLAN3) Unintentional firewall blocks (Central Services Domain block)
       4) Inability to tailor/customize services to RLAN hosts

  2. Create service instances inside the RLAN.

    1. ProsCons
      1) Parity with service offerings outside the RLAN (DHCP)                                                     1) Increased workload and resources
      2) Fewer firewall exceptions2) May require more hardware and/or software (e.g., in some cases, services would have to be duplicated)
      3) Less traffic crossing the RLAN edge 
      4) Better understanding of what things are inside the RLAN 
      5) Customized RLAN services (DNS with blacklisting) 
      6) More well-defined, tailored RLAN 

  3. A mixture of approach one and two.

    1. ProsCons
      1) same as above1) same as above                                                                                                                                            

      2) Reduces the administration overhead incurred by trying to meet every departments needs at the Firewall and possibly other RLAN protective measures. Pushing protective customizations down to the department level also allows them more flexibility within the larger constraints that central IT may choose to implement.