This slide covers how the physical layer networking of a campus should be designed. There are major weaknesses in this architecture in most campuses we have studied, which result in poor manageability and weak security.

High bandwidth backbone: movement of large files: The academic LAN backbone needs to have very high bandwidth to prevent chokes due to heavy student activity. Students usually have the time and inclination to play with audio and video files, most of them downloaded from peer-to-peer networks or ripped from optical disks. This, coupled with the large numbers of students, results in heavy LAN traffic on the backbones.

Layered architecture and VLANs: It is imporant to plan the entire campus network architecture in a systematic way keeping in mind the needs of the different zones within it. The central administrative complex is the innermost zone which has the Director, Registrar, or Principal, and other administrative staff. This zone handles two very important types of information: financial accounting and student grades. Both need careful design and access controls. The department academic complex includes all the faculty workstations, course curriculum related material, and typically carries one type of information students would love to get access to: question papers. The hostel connectivity covers the student residential areas and provides access to academic systems from hostels to let students access information and course work outside lecture hours. This connectivity poses security challenges because all accesses must be tagged with the identity of a bonafide student using his username and password. This is where RADIUS servers integrated to a central user database become very useful. The final layer is the wi-fi network which is sometimes exposed to even more outside attack and intrusion than the hostel connectivity. The wi-fi network is usually made available for laptop users to connect to the outer layers of the academic network for email checking, Web browsing, etc.

QoS on all backbone paths and Internet gateways: Given the high student traffic density, it is important that all bandwidth be controlled using QoS and traffic shaping mechanisms. For instance, if Web browsing is allowed uncontrolled bandwidth, then institute email flow may get delayed because of Internet bandwidth choke. Similarly, if Internet access from hostels is allowed uncontrolled bandwidth, then Internet access for official purposes from departments and the central admin complex may get adversely affected. Therefore, bandwidth budgeting is essential on all backbone links and Internet gateways.

L3 and L4 access control lists: Access control to services cannot be implemented only on mail or Web servers using usernames and passwords. It is important to control traffic patterns using IP-network based access controls, to ensure that access from one zone to another happens only in acceptable patterns. For instance, if only a few of the servers in the central administrative complex need to be accessed from the department complex, then only those servers should be made visible using IP-subnet based L3 ACLs in the backbone switches. If these servers in the admin complex are exporting only browser-based application interfaces, then access to the file serving or FTP ports should not be allowed; this can be enforced using L4 ACLs.

Authentication of all connections from student VLANs: It is very important that all connections originating from student VLANs, e.g. hostel connectivity, be authenticated using a username and password. It is impractical to control accesses based on IP addresses because there is no sanctity to the IP address settings for student-owned computers. Similarly, tying IP addresses to MAC addresses also is impractical, since MAC addresses today can be software-settable. Therefore, all connections, with no exceptions, should be permitted only after the initial hookup at the IP level is authenticated and authorized by a student's username and password. This can be implemented with modern L3 switches by integrating with back-end Merce servers running the RADIUS service, and the centralised Merce user database can provide the usernames and passwords.

Single point user management: the roll number: In a student environment, the roll number is usually unique across time, and can be used as a unique key to identify a user in all contexts. Merce can track any organisation-specific ID against a user in its database, therefore the roll number can be this ID which can be used in academic environments.