Restricted/Limited Access Network project meeting

Monday, November 4, 2013; 3:00 p.m.; AISB-208

Invited

Phil Benchoff, Jacob Dawson, Marc DeBonis, Brian Jones, Ron Keller, Philip Kobezak, Greg Kroll, Steve Lee, Randy Marchany, Rich Sparrow, Lucas Sullivan, Brad Tilley

Agenda

  1. Review action items and comments from 20130923 - September 23, 2013 RLAN Project Status Meeting
  2. Discuss charter reasons for having the RLAN (see comment below from Phil Benchoff)
  3. Open Forum

Attended

Phil Benchoff, Jacob Dawson, Philip Kobezak, Greg Kroll, Steve Lee, Randy Marchany, Rich Sparrow, Lucas Sullivan, Brad Tilley

Meeting Notes

  1. Review action items and comments from 20130923 - September 23, 2013 RLAN Project Status Meeting
    1. Action item: Ron volunteered to show Phillip how to use the CNS engineering change order system and be sure he understands how the system flows.
      1. Has not happened yet. Phillip will contact Ron.
    2. Action item: Include the ITSO sys log server in the whitelist. Action item: Include VBI Linux mirror machine in the whitelist.
      1. See #2 below discussing need to build a whitelist.
    3. Action item: Brian will review the current MOU and contact the ITSO when ready to discuss.
      1. Status unknown.
  2. Discuss charter reasons for having the RLAN (see comment below from Phil Benchoff)
    1. Randy commented that none of the original points for creating the RLAN have changed.
    2. Departments want to use the RLAN but are having trouble coming up with a whitelist of sites that the department uses. They have asked the ITSO for help. The ITSO proposes to:
      1. Temporarily remove the ASA(s).
      2. Block inbound traffic to the RLAN.
      3. Open/Log outbound traffic from the RLAN to anywhere so the ITSO can "profile" where the department is going and build a whitelist for them.
      4. THe department would then be responsible for reviewing and vetting the whitelist for production use.
      5. All this is temporary until a good whitelist can be created.
      6. Phil commented that this approach is going to create more work for everyone and there should be no general access to the Internet from the RLAN as that defeats its whole purpose.
      7. A discussion ensued about using the Unified Communications phone port for access to the RLAN in order to get more people using it.
        1. Technically it is possible. The restriction with the UC phones is that only one VLAN can be run through the phones so anyone using the UC phone to access the RLAN will only be able to get access through the RLAN.
        2. In addition the phones need to boot on a network with special DHCP options configured. I'm not 100% sure we can do what we need on an RLAN VLAN
        3. Administratively it was decided that the UC phone would not be used for the RLAN. Action item: Randy will talk to William about using the UC phones to temporarily access the RLAN.
        4. Action item: Randy will send Steve an email requesting the above temporary network changes .
  • No labels

2 Comments

  1. Greg Kroll

    Oct 21, 2013

    ----Original Message----
    From: Benchoff, Phil benchoff@vt.edu
    Sent: Thursday, October 03, 2013 8:31 PM
    To: Kroll, Greg
    Cc: Marchany, Randolph; Kobezak, Philip; Jones, Brian; Keller, Ronald; Lee, Steven; Dawson, Jacob; Sparrow, Rich; Sullivan, Lucas; Tilley, Richard
    Subject: Re: Agenda items for 10/8/2013 RLAN Phase 2 project status meeting

    On Thu, Oct 03, 2013 at 09:57:04AM -0400, Kroll, Greg wrote:
    > If you have agenda items for Monday's meeting please send them to me.
    > Thanks.
    >
    > --Greg

    In the past few meetings I have attended we have questioned whether certain ideas are appropriate for the RLAN. When we met with Scott for the first time to explain the RLAN, I did an outline and I don't know if we have found that document during the meetings.

    https://wiki.cns.vt.edu/x/yYj9Ag is what I have been talking about.

    I prepared that because we have always fought against the site firewall mentality and I put a good deal of thought into how the RLAN is actually different and how it could be beneficial before supporting the idea.

    It is probably appropriate for us to add a little more meat to that outline before we move on with the RLAN. You can bet that some pointy-haired Bozo accountant is going to come along and suggest that we need a site firewall or that RLAN users don't really need both a sensitive and general-use environment. These are the critical factors that allow it to have a chance to be useful.

    We all understand that the role of the network in securing a desktop is minimal. The real point of the RLAN is that only a small subset of users can join (R is for restricted-access), their machines have to meet the ITSO's system management standards, they can only get to pre-approved sites, and we can't manage this network with the availability of the general campus network. I believe we are learning that last point quite well as we go through the pilot.

    Those of you who have not played this game as long as Randy and I have may think that all those points are obvious, but they are not to the people that live isolated from the reality of managing actual systems. We can both share stories fighting this battle with board members and university administration. The firewall-is-all-you-need mentality still exists.

    In five or ten years, pointy-haired bean counters may have checklists that recognize that borderless environments are the reality. Until then, we're going to have to be prepared to deal with them.

    Randy is probably more tapped into the reality of what the so-called security experts believe these days, but it still looks grim from my point of view. I guess we have to wait for a Gartner report that says firewalls aren't all that useful.

    On the positive side, the RLAN is an opportunity for Virginia Tech to (here it comes) "invent the future" again. I am not fully convinced we can really get much out of the RLAN, but at least we have designed it with a acknowledgment of reality. I guess that's as good as we can get for now. The fact that we don't have a split academic and administrative environment is a great credit to the people that have fought against that for so long. The battle is not over though.

    I still have a backup plan. If we get pressed to compromise the principles behind the RLAN, we can just print stickers that say "RLAN" and put them on the portals. That will be just as effective and much cheaper. I know how to get stickers printed. https://plus.google.com/u/0/communities/106770754490175750511/stream/b6db3c27-9fea-49b9-8e97-6c27a3ef05a3

    Phil

  2. Greg Kroll

    Nov 06, 2013

    ---- Original Message ----
    From: Benchoff, Phil benchoff@vt.edu
    Sent: Monday, November 04, 2013 5:29 PM
    To: Kroll, Greg
    Cc: Marchany, Randolph; Kobezak, Philip; Jones, Brian; Keller, Ronald; Lee, Steven; Dawson, Jacob; Sparrow, Rich; Sullivan, Lucas; Tilley, Richard
    Subject: Re: Agenda items for 11/4/2013 RLAN Phase 2 project status meeting

    Re RLAN via phone:

    Rkeller pointed out another problem. The phones need to boot on a network with special DHCP options configured. I'm not 100% sure we can do what we need on an RLAN VLAN.

    I still maintain that if the long-term plan is that there will be no general-use clients on the RLAN, we are only complicating the process of sorting out the access policy by allowing anyone on who does not have two machines (or equivalent) even temporarily. Essentially you are decreasing the signal-to-noise ratio in the traffic you have to sort through to figure out what is necessary for the RLAN. You are also increasing the chances that malware finds its way into the RLAN and can mount internal attacks on the other clients. The only benefit I can see to rushing hosts into the RLAN is the marginal amount of protection the in-line border elements can provide. That is very small.

    Also, don't forget that the equipment on the border of the RLAN has fairly limited bandwidth.

    Phil

    P.S.: I just remembered the other thing that prompted me to send the first note. It was the concept that there should not be IPv6 in the RLAN because the IPS/IDS is broken. That is another case where I sensed the perimeter-based mentality appearing on the horizon.