Re: [WIRELESS-LAN] NAT tracking question
I think you've got it! Responses inline... 1. student joins wlan and is presented with captive portal 2. student logs in to the captive portal They can use our captive portal or connect straight to our encrypted 802.1X SSID, which authenticates them on the fly. But, yes, we somehow learn the device ownership. 3a. if first time logging in, student is assigned 4 internal IP addresses (per building) and DHCP reservations are configured in the DHCP server(s) and device gets address from the reservation. 3b. If not first time logging in and reservation exists for this device, device gets address from reservation Yep. 3c. if not first time logging in and no reservation exists for this device, a new reservation is configured for the new device (up to 4) and device gets a lease. Well, if a device is connecting for the first time, but the user already has a group-of-four set aside for them ... then yes. Perhaps they connected a laptop in the morning, and a tablet in the afternoon. The tablet is assigned the second reservation slot. If this is their fifth device connecting, a new group-of-four is assigned. 4. student does their thing on their device, probably Netflix or some such. Maybe even school work. Let's go with Netflix :) The key is that our F5 NAT's each group-of-four to a unique public IP. And since a group-of-four is assigned to an individual user, we've effectively mapped a public IP to an individual user. 5. NAT translations/streams are logged and if needed can be traced back to an internal IP. 6. based on the internal IP reservation, you know the student. We can use the flow logs to determine which of the four devices were responsible for an individual flow, but if we can't pin it down 100% (perhaps the timestamp is wrong, or we don't get a port number), we at least know the public IP -- student mapping. Do I assume that you clear your reservations on a yearly or semester basis? Right now, yearly. We've discussed releasing the reservations more often (say, after three months of inactivity), allowing us to accommodate more devices. But, at this point, we've still plenty of room for growth. Norman On Tue, Feb 24, 2015 at 10:22 AM, Oliver, Jeff jeff.oli...@uleth.ca wrote: Thanks Norm, really appreciated. Just to be clear and make sure that I am understanding your setup (high level anyway) 1. student joins wlan and is presented with captive portal 2. student logs in to the captive portal 3a. if first time logging in, student is assigned 4 internal IP addresses (per building) and DHCP reservations are configured in the DHCP server(s) and device gets address from the reservation. 3b. If not first time logging in and reservation exists for this device, device gets address from reservation 3c. if not first time logging in and no reservation exists for this device, a new reservation is configured for the new device (up to 4) and device gets a lease. 4. student does their thing on their device, probably Netflix or some such. Maybe even school work. 5. NAT translations/streams are logged and if needed can be traced back to an internal IP. 6. based on the internal IP reservation, you know the student. Anything that I have missed? Do I assume that you clear your reservations on a yearly or semester basis? Cheers, Jeff -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Norman Elton Sent: Tuesday, February 24, 2015 7:57 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] NAT tracking question Here's a write-up I did a few months back. I'm happy to elaborate as needed! Norman Elton College of William Mary = We recently converted to NAT, to solve two issues. The obvious is the growth in wireless devices. Our five /21s simply couldn't keep up with the demand, and we got tired of shoehorning extra subnets to accommodate. We were also concerned with the amount of broadcast traffic, which being sent at the lowest supported data rate, was needlessly occupying airtime. We knew some sort of NAT was in our future, and we wanted it partitioned down to the building (or region) level to contain broadcast traffic. But our security folks were apprehensive about tracking usage. Even with flow logs, responding to a DMCA complaint could take a significant amount of research. We brainstormed, whiteboarded, and head-scratched. Wouldn't it be nice if each student had exactly one public IP address, which front-ended whatever devices they had on campus, where-ever they were located? This would require some sort of deterministic NAT, whereby the NAT appliance knows the owner of a particular internal IP address, mapping any outbound traffic to the public IP address associated with that user. Here's how we got there... Each building (or region) is assigned a /16 within 100.64.0.0/10 (reserved for
RE: [WIRELESS-LAN] NAT tracking question
Thanks Norman, really appreciate it. Anyone know if Cisco's front end equipment is capable of this or similar? Cheers, Jeff -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Norman Elton Sent: Tuesday, February 24, 2015 1:23 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] NAT tracking question I think you've got it! Responses inline... 1. student joins wlan and is presented with captive portal 2. student logs in to the captive portal They can use our captive portal or connect straight to our encrypted 802.1X SSID, which authenticates them on the fly. But, yes, we somehow learn the device ownership. 3a. if first time logging in, student is assigned 4 internal IP addresses (per building) and DHCP reservations are configured in the DHCP server(s) and device gets address from the reservation. 3b. If not first time logging in and reservation exists for this device, device gets address from reservation Yep. 3c. if not first time logging in and no reservation exists for this device, a new reservation is configured for the new device (up to 4) and device gets a lease. Well, if a device is connecting for the first time, but the user already has a group-of-four set aside for them ... then yes. Perhaps they connected a laptop in the morning, and a tablet in the afternoon. The tablet is assigned the second reservation slot. If this is their fifth device connecting, a new group-of-four is assigned. 4. student does their thing on their device, probably Netflix or some such. Maybe even school work. Let's go with Netflix :) The key is that our F5 NAT's each group-of-four to a unique public IP. And since a group-of-four is assigned to an individual user, we've effectively mapped a public IP to an individual user. 5. NAT translations/streams are logged and if needed can be traced back to an internal IP. 6. based on the internal IP reservation, you know the student. We can use the flow logs to determine which of the four devices were responsible for an individual flow, but if we can't pin it down 100% (perhaps the timestamp is wrong, or we don't get a port number), we at least know the public IP -- student mapping. Do I assume that you clear your reservations on a yearly or semester basis? Right now, yearly. We've discussed releasing the reservations more often (say, after three months of inactivity), allowing us to accommodate more devices. But, at this point, we've still plenty of room for growth. Norman On Tue, Feb 24, 2015 at 10:22 AM, Oliver, Jeff jeff.oli...@uleth.ca wrote: Thanks Norm, really appreciated. Just to be clear and make sure that I am understanding your setup (high level anyway) 1. student joins wlan and is presented with captive portal 2. student logs in to the captive portal 3a. if first time logging in, student is assigned 4 internal IP addresses (per building) and DHCP reservations are configured in the DHCP server(s) and device gets address from the reservation. 3b. If not first time logging in and reservation exists for this device, device gets address from reservation 3c. if not first time logging in and no reservation exists for this device, a new reservation is configured for the new device (up to 4) and device gets a lease. 4. student does their thing on their device, probably Netflix or some such. Maybe even school work. 5. NAT translations/streams are logged and if needed can be traced back to an internal IP. 6. based on the internal IP reservation, you know the student. Anything that I have missed? Do I assume that you clear your reservations on a yearly or semester basis? Cheers, Jeff -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Norman Elton Sent: Tuesday, February 24, 2015 7:57 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] NAT tracking question Here's a write-up I did a few months back. I'm happy to elaborate as needed! Norman Elton College of William Mary = We recently converted to NAT, to solve two issues. The obvious is the growth in wireless devices. Our five /21s simply couldn't keep up with the demand, and we got tired of shoehorning extra subnets to accommodate. We were also concerned with the amount of broadcast traffic, which being sent at the lowest supported data rate, was needlessly occupying airtime. We knew some sort of NAT was in our future, and we wanted it partitioned down to the building (or region) level to contain broadcast traffic. But our security folks were apprehensive about tracking usage. Even with flow logs, responding to a DMCA complaint could take a significant amount of research. We brainstormed, whiteboarded, and head-scratched. Wouldn't it be nice if each student had exactly one
Re: [WIRELESS-LAN] NAT tracking question
Here's a write-up I did a few months back. I'm happy to elaborate as needed! Norman Elton College of William Mary = We recently converted to NAT, to solve two issues. The obvious is the growth in wireless devices. Our five /21s simply couldn't keep up with the demand, and we got tired of shoehorning extra subnets to accommodate. We were also concerned with the amount of broadcast traffic, which being sent at the lowest supported data rate, was needlessly occupying airtime. We knew some sort of NAT was in our future, and we wanted it partitioned down to the building (or region) level to contain broadcast traffic. But our security folks were apprehensive about tracking usage. Even with flow logs, responding to a DMCA complaint could take a significant amount of research. We brainstormed, whiteboarded, and head-scratched. Wouldn't it be nice if each student had exactly one public IP address, which front-ended whatever devices they had on campus, where-ever they were located? This would require some sort of deterministic NAT, whereby the NAT appliance knows the owner of a particular internal IP address, mapping any outbound traffic to the public IP address associated with that user. Here's how we got there... Each building (or region) is assigned a /16 within 100.64.0.0/10 (reserved for CG-NAT). So, Jones Hall would be 100.72.0.0/16. A student computer, upon being authenticated to our NAC system, is immediately assigned an IP address within every building's /16. In fact, they are assigned the same last two octets across our entire campus. So a student roaming across campus would get 100.###.154.24, where the second octet corresponds to their local building number. When we assign an address to a device (say, 154.24), we reserve a block of four contiguous IP addresses for that particular user. So if their laptop, being seen first on the network, gets assigned 154.24, their iPad might get 154.25, their phone would get 154.26. If they need more than four addresses, we reserve them another block. Remember these assignments represent the last two octets of the device's IP address. The first two are dependent on the building (100.72 = Jones Hall, etc). All of this IP address logic allows the actual NAT to run very fast, with very little logic. The outbound NAT is handled by an F5 Local Traffic Manager, in our case, a 4000S. This box can handle very rich NAT applications using their iRules. In our case, it uses a simple mathematical algorithm to examine the incoming IP address, mapping each block-of-four internal addresses, regardless of building, to a single public IP address. It sounds complicated, but it boils down to 10-12 lines of iRules logic. The magic is really the glue between our NAC system and our DHCP servers. As soon as we learn the ownership of an onboarded system, we determine an IP address and jam it into our DHCP server. The vast majority (96%) of our students have four or fewer devices. So they occupy a single block of contiguous IP addresses. A small percentage have five or more computers, so they actually are given two blocks of addresses, which correspond to two public IP addresses. Admittedly, this is hard to explain. It takes a few passes. And we were a bit apprehensive about how it would scale. But, surprisingly, it's working like a champ. No timeout values, no indeterminate NAT. Room for growth. No need to dive into flow records, our security folks are happy. The only hiccup, and it was not unexpected, involves supporting game consoles. Unlike your home Linksys router, the F5 does not support uPNP. This will likely impact anyone doing NAT on an enterprise firewall. Some peer-to-peer games do not work. But since a particular game console is always assigned the same public IP address, we can configure an inbound NAT rule for applications that use fixed ports. This comes up VERY rarely (maybe three or four times so far). On Tue, Feb 24, 2015 at 9:33 AM, Oliver, Jeff jeff.oli...@uleth.ca wrote: Hey Norm, For those of us with limited IP space, this sounds really interesting. Not sure if it belongs on the listserv or not (feel free to contact me off-line) but I am interested in your setup/config and would like to know more about it. Would you be able to supply some details? --- Jeff From: Norman Elton normel...@gmail.com Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Date: Monday, February 23, 2015 8:11 PM To: The EDUCAUSE Wireless Issues Constituent Group Listserv WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] NAT tracking question We deterministicly NAT up to four devices for an individual user to a single public IP. As our typical user has less than four devices, it works out that most students have a single public IP assigned to them. Should they authenticate a fifth device, a second IP is assigned to cover devices five, six, seven, and eight. The effect is that we've quadrupled
Re: [WIRELESS-LAN] LTE-LAA...anyone?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 This sounds as the same thing as UMA, using GSM/UMTS. Remember, operators to offer home free or hotspot calling? This effectively was realized with UMA, using Wi-Fi signals to carry GSM/UMTS traffic. An alternative for upgrading your Wi-Fi AP with a GSM/UMTS/LTE module to offer 2G/3G/4G services (for Cisco, see http://www.cisco.com/c/en/us/products/collateral/wireless/universal-small-cell-5000-series/datasheet-c78-730979.html). I see it as an opportunity to solve the bad indoor coverage. As an alternative to DAS that requires a separate coax infrastructure. Probably the upper band of the 5Ghz spectrum is interesting for LTE-LAA, because it allows transmitting more power. - -Frans Philippe Hanset schreef op 24/02/15 om 14:54: We could have dreamed that 5 GHz was this “clean” spectrum that all our users were going to move to and simplify our life a bit! but wait... the carriers have decided that they could use it too (ever heard of LTE-LAA?) Why would carriers stay in their contained and expensive Licensed Spectrum when they could use the Unlicensed one… https://gigaom.com/2015/01/05/ericsson-unleashes-lte-over-the-wi-fi-airwaves/ The theory is that LTE-LAA will play nice with Wi-Fi …. in theory! Can you hear the pitch already? Hello Mr CIO, we can take care of all your Wi-Fi needs for campus with a very reliable technology. No upfront cost to you, no Help Desk to deal with. Just a minimal monthly fee for all you users that are already our customers anyway. And we deal with DMCA... LTE-LAA sounds like that very polite good looking neighbor that moves next door and that eventually steels your spouse! Philippe Philippe Hanset www.anyroam.net http://www.anyroam.net ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU7JVfAAoJENxLkbYMq+PBPSsIAOAPaMh52nphojHhklPeWNjl D9OiMeauoJW4EWZnhqjEC3/5qfBGKmoEPmFrla8RGVx+9V1R0ZAiJ3pNTrWeiH1/ 0edtGqn5AqChbb1gc6aYY3xogMfaGZhhfxVQYcnXVdvf7rSCzeI6gkKuPjB10EPf SsC9V44biRID96RwFkT/fFgLkOFvVHxZQ1hdC/qQ1JX4bk0JQ7t+5eh5NCorJx3k Rv1ZJJQSWGl3FOorlT6DJq8/Q3puO5Z1KLZDwcQ+9vbAo4GWxAZlm8Y/e8F58Cn5 DBRUp5tAU5mnf3hss7uuH3JXXWcqsJOk0ppWvX3uhDDdr/VBWKPYtDvOL6cfvbM= =WWT4 -END PGP SIGNATURE- ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
RE: [WIRELESS-LAN] NAT tracking question
Thanks Norm, really appreciated. Just to be clear and make sure that I am understanding your setup (high level anyway) 1. student joins wlan and is presented with captive portal 2. student logs in to the captive portal 3a. if first time logging in, student is assigned 4 internal IP addresses (per building) and DHCP reservations are configured in the DHCP server(s) and device gets address from the reservation. 3b. If not first time logging in and reservation exists for this device, device gets address from reservation 3c. if not first time logging in and no reservation exists for this device, a new reservation is configured for the new device (up to 4) and device gets a lease. 4. student does their thing on their device, probably Netflix or some such. Maybe even school work. 5. NAT translations/streams are logged and if needed can be traced back to an internal IP. 6. based on the internal IP reservation, you know the student. Anything that I have missed? Do I assume that you clear your reservations on a yearly or semester basis? Cheers, Jeff -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Norman Elton Sent: Tuesday, February 24, 2015 7:57 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] NAT tracking question Here's a write-up I did a few months back. I'm happy to elaborate as needed! Norman Elton College of William Mary = We recently converted to NAT, to solve two issues. The obvious is the growth in wireless devices. Our five /21s simply couldn't keep up with the demand, and we got tired of shoehorning extra subnets to accommodate. We were also concerned with the amount of broadcast traffic, which being sent at the lowest supported data rate, was needlessly occupying airtime. We knew some sort of NAT was in our future, and we wanted it partitioned down to the building (or region) level to contain broadcast traffic. But our security folks were apprehensive about tracking usage. Even with flow logs, responding to a DMCA complaint could take a significant amount of research. We brainstormed, whiteboarded, and head-scratched. Wouldn't it be nice if each student had exactly one public IP address, which front-ended whatever devices they had on campus, where-ever they were located? This would require some sort of deterministic NAT, whereby the NAT appliance knows the owner of a particular internal IP address, mapping any outbound traffic to the public IP address associated with that user. Here's how we got there... Each building (or region) is assigned a /16 within 100.64.0.0/10 (reserved for CG-NAT). So, Jones Hall would be 100.72.0.0/16. A student computer, upon being authenticated to our NAC system, is immediately assigned an IP address within every building's /16. In fact, they are assigned the same last two octets across our entire campus. So a student roaming across campus would get 100.###.154.24, where the second octet corresponds to their local building number. When we assign an address to a device (say, 154.24), we reserve a block of four contiguous IP addresses for that particular user. So if their laptop, being seen first on the network, gets assigned 154.24, their iPad might get 154.25, their phone would get 154.26. If they need more than four addresses, we reserve them another block. Remember these assignments represent the last two octets of the device's IP address. The first two are dependent on the building (100.72 = Jones Hall, etc). All of this IP address logic allows the actual NAT to run very fast, with very little logic. The outbound NAT is handled by an F5 Local Traffic Manager, in our case, a 4000S. This box can handle very rich NAT applications using their iRules. In our case, it uses a simple mathematical algorithm to examine the incoming IP address, mapping each block-of-four internal addresses, regardless of building, to a single public IP address. It sounds complicated, but it boils down to 10-12 lines of iRules logic. The magic is really the glue between our NAC system and our DHCP servers. As soon as we learn the ownership of an onboarded system, we determine an IP address and jam it into our DHCP server. The vast majority (96%) of our students have four or fewer devices. So they occupy a single block of contiguous IP addresses. A small percentage have five or more computers, so they actually are given two blocks of addresses, which correspond to two public IP addresses. Admittedly, this is hard to explain. It takes a few passes. And we were a bit apprehensive about how it would scale. But, surprisingly, it's working like a champ. No timeout values, no indeterminate NAT. Room for growth. No need to dive into flow records, our security folks are happy. The only hiccup, and it was not unexpected, involves supporting game consoles. Unlike your home Linksys router, the F5 does not support
LTE-LAA...anyone?
We could have dreamed that 5 GHz was this “clean” spectrum that all our users were going to move to and simplify our life a bit! but wait... the carriers have decided that they could use it too (ever heard of LTE-LAA?) Why would carriers stay in their contained and expensive Licensed Spectrum when they could use the Unlicensed one… https://gigaom.com/2015/01/05/ericsson-unleashes-lte-over-the-wi-fi-airwaves/ The theory is that LTE-LAA will play nice with Wi-Fi …. in theory! Can you hear the pitch already? Hello Mr CIO, we can take care of all your Wi-Fi needs for campus with a very reliable technology. No upfront cost to you, no Help Desk to deal with. Just a minimal monthly fee for all you users that are already our customers anyway. And we deal with DMCA... LTE-LAA sounds like that very polite good looking neighbor that moves next door and that eventually steels your spouse! Philippe Philippe Hanset www.anyroam.net ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [WIRELESS-LAN] NAT tracking question
Hey Norm, For those of us with limited IP space, this sounds really interesting. Not sure if it belongs on the listserv or not (feel free to contact me off-line) but I am interested in your setup/config and would like to know more about it. Would you be able to supply some details? --- Jeff From: Norman Elton normel...@gmail.commailto:normel...@gmail.com Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv WIRELESS-LAN@LISTSERV.EDUCAUSE.EDUmailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Date: Monday, February 23, 2015 8:11 PM To: The EDUCAUSE Wireless Issues Constituent Group Listserv WIRELESS-LAN@LISTSERV.EDUCAUSE.EDUmailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] NAT tracking question We deterministicly NAT up to four devices for an individual user to a single public IP. As our typical user has less than four devices, it works out that most students have a single public IP assigned to them. Should they authenticate a fifth device, a second IP is assigned to cover devices five, six, seven, and eight. The effect is that we've quadrupled our IP utilization. It's mostly a matter of handing out predetermined IP addresses which include a series of bits used to identify which group of four it should be NATed to. Our F5 box can examine the private IP, do a little bit shuffling, and calculate the corresponding public IP. This calculation is extremely light-weight, allowing the whole system to scale quite well. The heavy lifting occurs when the device is on boarded the first time, at which point a group of four is allocated for the user. Norman Elton College of William Mary On Monday, February 23, 2015, Chuck Anderson c...@wpi.edumailto:c...@wpi.edu wrote: If you have 1 public IP address reserved for each individual user, why do you need to do NAT at all? This is a serious question--if you aren't saving public IPs by doing 1:many NAT, why do NAT at all? Thanks. On Mon, Feb 23, 2015 at 11:33:45AM -0500, Norman Elton wrote: We play tricks with our ISC DHCP server and a pair of F5 LTMs (similar to the A10 gear). The DHCP server hands out predetermined private IP addresses to devices as soon as we determine ownership (through our NAC). For outbound traffic, the F5 uses this private IP address to NAT to a public IP address that is reserved for the individual user. The end result is that no matter where the device is on campus, we know that 128.239.x.y is something owned by Joe Smith. If we need to know exactly which device, we consult our flow logs. But at least we're 99% confident we're dealing with the right student. I'm happy to share the gory details if someone wants to wrap their head around it. Norman Elton College of William Mary On Mon, Feb 23, 2015 at 10:30 AM, Danny Eaton dannyea...@rice.edujavascript:; wrote: We've got our Juniper SRX 5800 doing our NAT for all wireless, plus all students and visitors (wired or wireless). We send those logs (and the SRX is VERY CHATTY about NAT) to our Splunk server for the tying together of date/time, public IP and private IP - in the event we get a notice from some TLA. -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDUjavascript:;] On Behalf Of Heath Barnhart Sent: Monday, February 23, 2015 9:12 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDUjavascript:; Subject: Re: [WIRELESS-LAN] NAT tracking question We use a Sonicwall E8500 for NAT, it will log all NAT translations and send them as syslog to a server for storage. I have logrotate changing files every hour to make it easier to search on. -- Heath Barnhart ITS Network Administrator Washburn University Topeka, KS On Wed, 2015-01-14 at 14:49 -0500, Jerry Bucklaew wrote: To ALL: We have a large Cisco wireless deployment with public ip address space. Getting more public IP's is getting difficult so we are considering going to NAT. The issue we have with NAT is that we still want to be able to map an outside IP back to a individual user. Once you go to NAT that of course becomes more difficult to do. I know a lot of you are probably already doing this and I was wondering how and what products do you use? I assume most have a one to many NAT and then use something like a netflow collector to to track the inside NAT IP to the outside Src-IP/DST-IP/Port/Time. Any good working solutions or products would be helpful. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
