i
If you are not redirected automatically, follow the link to
Network Policies
|
Policy and expectations for the SLAC Visitor and Wireless networks.
Les Cottrell
Page created: February 11, 2002. Last Update: 21 November, 2011 (Les Cottrell).
Version 1.2
|
|
This page provides the policies and expectations for the Visitors subnet at SLAC.
General guidelines for all SLAC subnets
- By policy, unless approved by SLAC networking, SLAC does not provide
spare ports in offices, in case a casual user might want to connect
to the SLAC network. Such ports are generally made available in public
areas and are on
the Visitors subnet. If extra ports are required in offices then the
requester will need to
justify and provide an account to charge. An example of such a requirement
is for an office or areas where there are extra occupants such as students or
visitors who are at SLAC for a short time.
- Shared hubs or unapproved switches not approved by SLAC
networking must not be connected to existing switched
ports (e.g. to add extra connections).
Not only does this violate the policy on
No Tampering with Telephone, Networking cables or Equipment, but also adding such
hubs/switches can cause problems with the switch ports, and in the case of hubs reduces security since they facilitate
sniffing of passwords etc.
- Only people who have read and agreed to the
SLAC
appropriate use document
may use computers on SLAC subnets. A SLAC userid and password is
required to access many of SLAC's computer services. A corollary is that,
computers with guest accounts with no password
are not allowed inside the SLAC firewall, since they could access
SLAC protected services.
- SLAC printers are strongly encouraged to be placed with an address in the
SLAC Internet Free Zone (IFZ).
- We are reviewing where to place hosts that run an unsupported operating
system (e.g. Windows 98 or Debian Linux), at the moment we encourage that
they be placed on the Visitor's subnet.
For more on the Visitor's network, see:
The SLAC Visitor Network.
- The Visitors subnet is located outside the SLAC firewall.
Thus its security is the same as connecting
to an ISP. It is the responsibility of users
of the Visitors subnet to
protect their communications, e.g. by using a Virtual private Network (VPN).
Do NOT use applications (such as POP/IMAP/FTP/telnet)
that will put unencrypted passwords onto the network.
- The Visitors subnet is meant for light casual use, including mobile SLAC user,
visitors
such as occasional collaborators, conference/meeting attendees,
vendor demonstrations, and people not registered at SLAC.
- We monitor the utilization of the Visitor subnet looking for
capacity issues, so we can add more capacity when needed. We also scan it
for vulnerabilities such as unencrypted passwords.
- Like other networks at SLAC, the Visitor network receives
best effort service.
If a critical problem is reported we will try and address the issue
in a timely fashion.
Priority for addressing problems will naturally go to networks
which are more critical to the SLAC mission.
- The Visitor subnet is different from other subnets:
- Hosts do not have to be
registered, hosts are automatically
given dynamic IP addresses and names by DHCP.
This makes it harder
to track down problems, so problems may take longer to solve.
- Server ports, apart from appropriately registered ports,
are blocked to the Visitor subnet so servers should not
be placed on this subnet. The following servers are supported on
the visitor's subnet: anonymous DHCP, Citrix terminal server,
wireless access server.
- Given the above caveats, do not place mission critical applications
on the Visitor subnet.
- SLAC supported printers can be accessed from the visitor's subnet using
printserv.slac.stanford.edu (alias lpd01), see
Printing
using LPR in Windows.
- Hosts on the visitor network that are seen as possible 'scanning hosts',
including those that might be running SKYPE as a supernode (or some other P2P
software) will be put in the
penalty box
and have their network speed and throughput drastically reduced.
Anyone interested in deploying:
-
802.11 wireless network
technologies,
- or devices such as cordless phones, microwave ovens,
wireless controllers, or remote device connections (such as a VGA screen)
that use the 802.11 frequencies (2.4, 3.6, 5GHz)
that may interfere with other devices at SLAC,
must contact SLAC Networking (email to net-admin with the relevant information)
before initiating any such purchases
or starting any SLAC 802.11 deployment planning.
Mission critical applications must use the wired network.
Currently Wireless Access Ports (WAPs)
are only placed on the Visitor subnet and so fall under the
policies and expectations
above.
WAPs for new
installations are funded from
group/department budgets. After purchase, the WAPs are owned, configured,
supported and maintained centrally.
Discussion on wireless access
Since the available wireless spectrum is shared, it is
inherently impossible to guarantee performance and reliability levels for
wireless networking. Furthermore higher priority will be
given to supporting the wired network since it supports mission critical
applications (see above).
Dedicated resources are needed at SLAC to support surveys of wireless strengths
by location, trouble-shooting, new installation planning and
spectrum optimization.
Other items to be aware of include:
- The wireless network is a shared medium, so:
- There is a fixed limit on the aggregate bandwidth for an access
point.
- Passwords and other information can be sniffed.
- The maximum bandwidth available to a host depends on distance from the access point,
attenuation and noise
and typically is in the 1-4 Mbits/s. range.
It is thus critical to:
- avoid interference with other wireless deployments such as ongoing
SLAC research activities sensitive to wireless networking frequencies,
- ensure interoperability,
- network security,
- and network reliability.
For more information on the wireless network see:
Wireless Networking at SLAC.
[ Feedback | Reporting Problems ]
Owners: Les Cottrell and
Antonio Ceseracciu