From: Greg Liddle (gregory.w.liddle@wheaton.edu)
Date: Tue Apr 17 2001 - 12:31:04 CDT
We are using a more complex overall system in conjunction with Netreg, so
some of the ideas I'll address below may be too much effort for the benefit
you would receive, but here's some food for thought.
Several of the enhancements that we've considered include:
1- multiple IP's per student
2- tighter security based on location of registration
3- automatic subnet assignment based on flags (discipline reasons)
4- mobility & security
5- registration tracking
BACKGROUND
We use a MySQL database in conjunction with Netreg to do our authorization &
address assignment. It contains a table which has student information in
it, including the (single) IP address that we've pre-assigned to each
student. This table is populated via SQL queries from our student
information system, which housing uses.
We currently allow one IP per student, but that is primarily for billing
purposes, rather than lack of IP address availability. We also use just one
subnet for our 2250 (only 1250 live this year) ports on ResNet, in a
completely switched environment (HP & 3Com on edges, Cabletron w/SecureFast
VLAN on backbone).
COMING CHANGES
Next year, all service charges are going to be part of room costs, and we're
considering allowing multiple machines per student. In addition, we have a
policy that mis-behaving students end up with restricted (campus-only)
access. This is enforced (lightly) using an address range that we won't
route out of campus. (Yes this assumes DHCP compliance, but we also monitor
via SecureFast any IP/MAC changes.) This policy is currently completely
manually enforced.
IDEAS & SOLUTIONS
1-- By adding a table into MySQL, containing all the available IP addresses
that can be assigned, we can allow multiple IP assignments per student.
Upon registration, the query which normally looked up an IP from the
student's record would instead look up the first unassigned IP from the IP
table, and then mark that address as assigned to that student. Flags could
be used in both the student's record and the IP table to limit or narrow the
scope of this (see 3 below). The number of addresses allowed per student
could be governed by a field in the student table, and could be 0, 1, 3, 10,
etc... Whatever you can handle.
A zero would prevent a student from being able to register, if necessary.
2-- Our edge switches (3Com and HP) allow SNMP queries to be run against
them. An idea we had to enhance security included using our student info
(in the database) to identify which switch & port they should be connecting
through, and then querying the switch to see if that address was currently
on that port. If so, allow a registration, if not, tell them they need to
register from their own room. Conceptually simple, but more difficult to
implement. I think it would work, however. When combined with the
"security" features on the switches, it could prevent the 'register down the
hall' problem.
3-- We want to be able to set a discipline flag on a student's record, which
would be read during their registration, and would then assign an IP that
was not routed outside our network. Using the student table AND the IP
table, and some logic in the register.cgi program, we could pull up only
addresses that meet our criteria for any student that has a discipline
boolean set to TRUE in their record. This concept also could be used to
assign to a subnet based on building, floor, hair color, ... ;-)
4-- by implementing the registration snmp-location screening, we can be
fairly certain that the person registering is who they say they are (the
database also allows us to verify against more than just a password/email
combo). After the registration, they are then free to use their computer
anywhere on our network. We have tried using port security features before,
but found them to be cumbersome, and not very standard across manufacturers.
The only way we would use this now is via snmp management. If you used it
though, you could control which areas are "open-access", and which are a
"first-come, only-served" basis.
5-- Registration tracking is an integral part of how we're setup, since we
run billing from it. We track the date of registration, and bill in a
pro-rated fashion. For other reasons, though, it's good to know when a user
registered. By tracking this in the IP assignment table, it is readily
accessible for other kinds of analyses, like how long it took to reach XX #
of subscribers in the fall, etc.
SAMPLE TABLE STRUCTURES in MySQL
Student table:
StudentID
FirstName
LastName
DormRoomCode
Switch
Port
FlagDiscipline
IPLimit
PinNum
4DigSSN (or Mother's maiden name... whatever your system tracks)
(FlagSubnet?)
IP_table:
IP
DNS_Name
Subnet
(ExpireDate) (for periodic cleanup)
StudentID (assigned during reg)
OS
Reg_date
MAC
If this hasn't fried your brain, feel free to ask more questions.
--- Greg Liddle ResNet Manager Wheaton College gregory.w.liddle@wheaton.edu********************************************************************** To unsubscribe from this list, send an e-mail message to majordomo@southwestern.edu containing a single line with the words: unsubscribe netreg Send requests for assistance to: owner-netreg@southwestern.edu **********************************************************************
This archive was generated by hypermail 2.1.4 : Thu Aug 12 2004 - 12:01:35 CDT