Network Strategic Vision
Written by Mark Miyasaki.
Contents:
This document covers the strategic vision for Stanford University’s backbone data networking infrastructure SUNet, which provides the core data network connectivity for the campus, including residential areas.
Principles
Whether for research, student registration, procurement of goods and services, or any number of other mission critical and time sensitive transactions, SUNet has become one of the most critical resources that Stanford’s community relies on daily. Consumption of network bandwidth has grown rapidly, driven by numerous school initiatives to digitize media and make it available over the network.
The goal of Communication Services is to provide a network infrastructure that is reliable, robust and secure, and easily accessed from anywhere including both on- and off-campus.
Our services will be developed with the following principles in mind.
- Centralized services with local control: Develop services that are collaborative in nature. The services should be designed to be inclusive, not exclusive, of the Local Network Administrator (LNA) community of Stanford.
- Efficient, cost effective and scalable: Our services should be highly scalable in an efficient and cost effective manner, utilizing virtualization techniques wherever possible.
- Flexible and adaptable: Our services must be flexible in order to meet the highly diverse needs of Stanford, and be adaptable to the ever changing conditions, whether they are internally or externally driven.
In order to meet these goals, SUNet must first and foremost be engineered as a fault-tolerant network. This requires not only redundant network hardware with automatic failover, but also placement of core network components in geodiverse locations. In order to avoid an “all eggs in one basket” scenario, network hub points are distributed across multiple, semi-autonomous areas known as Operational Zones (OZs).
It is no longer sufficient to only protect SUNet from external security threats. As important is protecting University resources from internal attacks. In order to provide a secure network environment, the Departmental Firewall service is available at the perimeter of each departmental network.
SUNet must have enough capacity to meet the bandwidth demands placed on the network today and over the next several years. The network must be architected to avoid creating bottlenecks by providing an efficient path between all departments and key network based services.
Finally, wireless network connectivity should be available in all buildings and open spaces within the academic campus. Remote connectivity to SUNet from off-campus should be easily and globally available in a seamless manner, regardless of the connection methodology, e.g., wireless, broadband or dialup.
In addition to SUNet, Communication Services currently operates three other backbone networks across campus: wireless, voice services, and building security networks. These distinct networks, each with their own fiber optic transport is necessary in order to meet security, performance, or operational requirements.
Technologies
Operational Zones:
The current SUNet backbone network consists of ten semi-autonomous areas known as Operational Zones (OZ). This structure allows for containment of a major incident to within one OZ, allowing the rest of the campus to continue operations and limiting the overall incident impact. Each OZ comprises a redundant pair of routers, firewalls and distribution switches. For easier identification, each OZ is color-coded. The OZs that are deployed into production are:
Physical separation of the primary and secondary network devices in different Electronic Communications Hubs (ECH) facilitates continuous operation even in the event of a device or power failure in one of the ECHs. In the event of a failure, the fail-over to the corresponding backup system is automatic.
Each OZ maintains multiple Layer3 connections utilizing the BGP routing protocol into the core of SUNet, the Backbone Routers (BBR).
These multiple L3 connections into the core ensures that each OZ will continue to operate seamlessly without having to fail-over to its backup hardware should one of the backbone router-pairs fail.
Security Zones:
Each OZ supports 30–50 departmental networks. Within each OZ, departmental networks are provided with their own security zone, accomplished by partitioning the firewall into multiple virtual systems (v-sys), each capable of operating with a unique set of administrators and policies. The use of these virtual systems permits greater flexibility in meeting the unique needs of each Stanford department, while protecting from attacks originating both external and internal to SUNet. These security zones also allow for containment of a major security threat at a departmental network level.
10Gbps Ethernet:
All network connections between the core backbone routers, the OZ routers, and OZ distribution switches will be built utilizing 10Gbps Ethernet technology, ensuring that SUNet will have enough capacity to meet the bandwidth needs of the Stanford community for the next several years.
NetDB:
NetDB is a key element in the operation of SUNet. The NetDB database contains information about all of SUNet's physical components and their relationships, including host computers, workstations, terminal servers, routers, switches, etc. NetDB provides a mechanism for assigning and registering a unique name and Internet Protocol (IP) address to each networked device — a requirement before a computer is permitted to operate on SUNet. NetDB also provides input to various network software services, such as the Domain Name System (DNS), the SUNet DHCP service, and the SUNet Whois service.
Stanford Network Self-Registration (SNSR):
Protecting against network-based attacks at the departmental network perimeter is only part of the solution to providing a secure network environment. Another key element of network security is to improve the security of computers and to have them accurately registered in NetDB. SNSR combines a web-based self-registration tool that simplifies the registration process and gathers accurate information into NetDB. SNSR also provides a computer health check tool that is run as part of the registration process to ensure that the latest software updates and Antivirus software are loaded, and security tools such as BigFix are installed.
Future state
SUNet:
Utilizing MPLS (Multi Protocol Label Switching), the existing backbone networks (core data, wireless, voice services and building security) will converge into a single backbone network. MPLS provides for the capability to operate multiple separate instances of virtual routers on a single platform, in essence virtualizing SUNET. In doing so it creates a scalable, efficient and cost effective network infrastructure that provides for greater flexibility in meeting the diverse needs of Stanford and reducing the time to deliver services across campus.
SUNac:
Currently, IT Services support two separate VPN services to meet the needs of the campus. The Public VPN service is available to members of the campus community with SUNet IDs, and provides broad access to the general Stanford network. The Administrative VPN service is tailored to provide a more granular level of access, typically to administrative applications behind firewalled networks within the data centers. With the widespread adoption of the departmental firewall service at Stanford, a scalable mechanism for providing granular access control is needed for the general campus.
SUNac, Stanford University Network Access Control, provides LNAs with the ability to grant remote access based upon an individual’s SUNet ID to departmental resources located behind IT Services managed firewalls. With SUNac, the public and administrative VPNs will be consolidated to a single VPN infrastructure that meets the security needs of both the departmental network and administrative applications. SUNac will also allow us to offer multiple types of VPN access, from IP-SEC VPN to SSL VPN, allowing for greater flexibility and choice for end users.
Wireless Access:
Wireless LANs have grown in coverage over the past seven years at Stanford, with over 3,200 wireless access points deployed to date. Past wireless deployments have focused on providing as much coverage as possible. Current and future efforts will focus on making the wireless LAN service more robust by providing denser coverage to areas where usage is high, and in doing so increase capacity and fault tolerance.
The rapidly increasing demand for access to the wireless network is severely straining a finite resource — public IP addresses. To meet the increasing demand for IP addresses on the wireless network, private IP addresses will be assigned with NAT (Network Address Translation) addresses provided for wireless access to network resources outside SUNet.
While WiFi will continue to be the wireless LAN technology in use within buildings, a more robust wireless technology with a longer range is needed to provide ubiquitous network access, whether on-campus or off-campus. WiMAX, a 4G WWAN technology, may be able to provide an always-connected Internet experience with sufficient network performance characteristics to satisfy user expectations. We will partner with Clearwire Corporation to deploy WiMAX access to the main Stanford campus as part of Clearwire’s Innovation Network, which covers 20 square miles in Silicon Valley.
DMCA Automated Resolution:
Working in partnership with the Information Security Office (ISO), Communication Systems is making changes to NetDB and the related DNS/DHCP services, to allow for automated resolution of security issues. Initially, this is being developed and deployed to automate the processing of DMCA (Digital Millennium Copyright Act) complaints. A new NetDB node state, called “frozen," is being added to NetDB. Nodes placed in the frozen state will have their fixed IP addresses placed into a special “view” on the campus DNS servers which will then answer all DNS queries from those nodes with the address of the automated resolution server. The user must take the necessary corrective action through the resolution server before being allowed back onto the network.
Projects
First:
- Enable SNSR on the Stanford Wireless Network, including providing provisions for registering smartphones.
- Deploy SUNAC as replacement for Public VPN.
- Enable IPV6 on external facing services.
- Architect, plan, and test a MPLS based SUNet.
- Reconfigure student residence WiFi network, physically separating the wireless and wired infrastructure, renumbering utilizing private IP addresses, and providing NAT service.
- Pilot WiMAX based services
Next:
- Implement virtualized SUNet utilizing MPLS.
- Deploy SUNAC as replacement for Administrative VPN.
- Enable SNSR on the Stanford Wireless Network.
- Enable IPV6 routing across Stanford.
- Implement WiMAX based production services.
Later:
- Increase departmental network access capacity into SUNet.
- Evaluate Flow Based Routing.
- Enhance network availability through automated network failure detection and correction.
MPLS: research how Multi-Protocol Label Switching technology can be leveraged on SUNet in order to provide differentiated IP network services and improve traffic engineering capabilities.
Flow Based Routing: research how this technology can be best utilized on the Stanford campus.
