One document matched: draft-ymbk-termroom-op-07.txt
Differences from draft-ymbk-termroom-op-06.txt
IETF Secretariat N. Bourbaki
INTERNET-DRAFT IETF
draft-ymbk-termroom-op-07.txt 2002.06.13
IETF Meeting Network Infrastructure Lore
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
0. Abstract
Creating and running the 'terminal room' for an IETF meeting is
tantamount to building, running, and dismantling a small computer
center. Although this is a well-known area of operations, the unique
environment and its ephemeral nature warrant passing on the lore in a
mildly organized fashion. It is expected that this document will be
updated regularly. However, it is not clear that this will ever be
published as an RFC.
As the IETF can ill afford failure of this service, it is assumed
that the host and organizers have the experience and resources to
build such environments, understand power facilities, cabling, WAN
and LAN building, workstation provisioning, staffing, etc. So this
document does not attempt to detail how to build computer facilities
or carry out prudent project management. Rather it concentrates on
the unique aspects of the IETF 'terminal room'.
N. Bourbaki Expires 2002.12.13 [Page 1]
INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 2002.06.13
1. External Network Connectivity
The picky and analytic nature of a large number of IETF participants
means that the connectivity and performance of that connectivity will
be measured, whined about, ... Do not worry. Move the packets well,
and the nit pickers will pick each other to death.
1.1 Bandwidth Requirements
Bandwidth consumption is approximately 5kbps per attendee. So
currently 10mbps of external connectivity seems sufficient.
Unicast peaks at about five, and multicast at three. The
addition of streaming services may require more bandwidth,
especially if they are not cached off-site.
1.2 Path Diversity
If possible, diverse physical and logical paths should be
provided. It is understood that few conference centers have
connectivity, let alone diversity. But it is prudent to
coordinate with the ISP to get as much redundancy as reasonably
possible. Redundant and diverse paths out of the local
provider's POP(s) are advised when possible.
1.3 WAN Multicast Considerations
It has been suggested that multicast WAN connectivity would
benefit from being separated from unicast. This has been tried
and worked, though it is not believed to be necessary.
1.4 IPv6 Considerations
Increasingly it is expected that IPv6 connectivity is available.
Ideally this would be via some production IPv6 service. If that
is not available, at least 6bone access SHOULD be provided.
2. The Internal Network
This has been the transport area of most concern at recent meetings.
The bulk of the users require IPv4 unicast. IPv4 multicast is needed
to originate MBONE content from selected Working Group sessions.
Some users who have forgotten how to walk or may be extremely
antisocial find it convenient to be able to receive the multicast
feeds and other multicast content. Increasingly, some form of IPv6
connectivity is desirable.
Like many academic computer centers, the IETF terminal room and LANs
get 24 hour use for the duration of the meeting. While users do not
N. Bourbaki Expires 2002.12.13 [Page 2]
INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 2002.06.13
expect staffed support at all times, they do expect the network to
remain up even at 2AM. IETF attendees often do not recover from jet
lag or operate on hacker [JARGON] schedules.
A number of IETF old-timers consistently show up on the Saturday
prior to the meeting; clever terminal room staff will leverage them
in helping to crimp, cable, and configure the terminal room setup.
Historically, terminal room staff who take a crisp officious view on
when the terminal room and wireless LAN first become available are
less successful than those who take a more flexible and friendly
approach.
While set-up will take a very large staff, if it has been done well,
the staff needs during the meeting are small. General experience has
been three to four people during the day, with some spares able to
cover during meals etc. Having someone on cell phone or in the same
hotel at night is prudent.
Most IPv4 multicast traffic originates from one of the two
concurrently operating multicast Working Group sessions. However,
some multicast will be originating outside and consumed by IETF
attendees in the terminal room. It is helpful if the IPv4 multicast
router supports IGMPv2 [RFC-2236].
While current use is primarily IPv4 unicast or IPv4 multicast, in
future the terminal room SHOULD also provide some form of IPv6
connectivity. If IPv6 [RFC-2460, RFC-2463] is deployed in the IETF
network, at least IPv6 Neighbor Discovery [RFC-2461] with stateless
autoconfiguration [RFC-2462] SHOULD be enabled to enable plug and
play networking.
2.1 LAN Separation
As they seem to interfere with each other, at least three
separately routed LAN segments SHOULD be used for the terminal
room, wireless ethernet, and multicast services. In particular,
the high speed multicast feed exceeds the capacity of the
wireless ethernet, and therefore MUST be separate. In case
multicast causes wireless problems, be prepared to keep all IP
multicast traffic off the wireless LAN.
There MUST NOT be firewalls, NATs, or other end-to-end breakage
between the public LAN(s) and the global internet.
2.2 Meeting Infrastructure Connectivity
The registration desk SHOULD be provisioned to accommodate the
Secretariat's firewall and LAN. It is also helpful if the
N. Bourbaki Expires 2002.12.13 [Page 3]
INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 2002.06.13
Wireless LAN (more below) has good coverage around the
registration desk.
The IAB/IESG meeting room SHOULD have LAN coverage, and it SHOULD
also have 802.11b wireless support.
2.3 Meeting Rooms
Two of the meeting rooms MUST be provisioned for origination of
IP multicast audio/video content. The IETF Secretariat will
specify which rooms shortly before setup.
2.4 Mains Power Availability
A scattering of mains power outlets in all meeting rooms is much
appreciated by laptop-based attendees. Having a few power strips
in the lobby, bar, and other places laptop users congregate is
also much appreciated. Wireless folk use large qualities of
power strips.
Attendees appreciate having advance notice of which sort of power
(i.e. voltage, frequency) and which sort of power connector will
be present at the meeting location. This permits attendees to
obtain appropriate adapters and widgets before coming to the
meeting. This information SHOULD be included on the IETF meeting
web page and SHOULD also be included in a message to the IETF
Announce mailing list.
2.5 Wireless LAN
Drops to connect the wireless ethernet base stations SHOULD be
supplied at strategic locations throughout the facility. The
primary targets should be large gathering areas with seating,
e.g. the lobby and bar areas. All meeting rooms SHOULD have
wireless coverage if at all possible.
Historically, IETF used Digital RoamAbouts, the proprietary pre-
standard WaveLAN technology that operated at 915 MHz (and 2.4 GHz
outside North America). Recently, the IETF user base has been
moving to the new IEEE Standard 802.11 wireless LAN technology at
2.4 GHz. This transition is now largely completeand the new IEEE
802.11 wireless standard [IEEE-99a] is dominant in the IETF user
base.
The IEEE standardized two incompatible variants within the 802.11
standards. One variant uses a Frequency Hopping Spread Spectrum
(FH) technique. This is commonly called IEEE 802.11-FH. The
second, far more widely deployed, variant uses a Direct Sequence
N. Bourbaki Expires 2002.12.13 [Page 4]
INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 2002.06.13
Spread Spectrum (DS) technique. This is commonly called IEEE
802.11-DS.
The IETF Wireless LAN MUST support at least the 802.11-DS
technology. As these systems are able to automatically scan all
the channels, the terminal room operator SHOULD configure
immediately adjacent Access Points to use different channels
within the 2.4 GHz band.
The IEEE recently approved a higher-performance (11 Mbps)
extension [IEEE-99b] to the basic 802.11 specification. The
802.11 Access Points SHOULD be configured to support the 11 Mbps
speed. However, the Access Points SHOULD NOT be locked to only
support 11 Mbps, as some attendees will have older PCMCIA cards
that only operate at the older, slower speeds.
It is assumed that attendees using wireless use (self-supplied)
end-to-end encryption (e.g. SSH, ESP) or are suicidal. So the
wireless network itself is run in the clear, i.e. encryption is
turned off.
If parameter values are chosen which are different from those
described in this document, substantial advance public notice
MUST be given to the IETF Announce mailing list and on the IETF
meeting web page.
To allow IPv6 operation, certain ethernet-layer multicast must be
able to go through the wireless links. Some wireless
basestations offer the ability to turn off bridging of ethernet-
layer multicast packets. You MUST configure basestations to
properly bridge at least ethernet-layer multicast as used by
IPv6, i.e. 33:33:xx:xx:xx:xx.
Any additional wireless types beyond the IETF supported wireless
standard, IEEE 802.11-DS, and all applicable user configuration
parameters SHOULD be announced on the IETF meeting web page and
to the IETF Announce mailing list well before the meeting so that
attendees have an opportunity to obtain compatible adapters for
their laptops. Examples of possible wireless additions include
the older proprietary 915 MHz or 2.4 GHz RoamAbouts and/or
802.11-FH.
2.5.1 Wireless LAN (IEEE 802.11-DS)
The IETF 802.11-DS systems and 802.11-FH systems have one primary
configuration parameter. This is variously called "ESS ID",
"Network Name", or "Network ID", depending on which documentation
one is reading. This parameter MUST be set to the 4 character
N. Bourbaki Expires 2002.12.13 [Page 5]
INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 2002.06.13
string "IETF" in all capital letters for the IETF 802.11 wireless
LANs. Encryption SHOULD be disabled (see comment in 2.5 above).
2.5.2 Wireless LAN (Historic)
Support for the older proprietary RoamAbout 915 MHz and 2.4 GHz
systems MAY be provided as a convenience to those attendees yet
to convert. The proprietary RoamAbout 915 MHz and 2.4 GHz wired-
to-wireless bridges have parameters global to all bridges which
MUST be set as follows:
Domain ID: 0x1
Beacon key: 0x1E1F
The proprietary RoamAbout 915 MHz and 2.4 GHz wired-to-wireless
bridges have a Network ID (NWID) parameter that MUST have a
unique value for each bridge location and which SHOULD be set as
follows:
1st location's NWID: 0xAAAA
2nd location's NWID: 0xBBBB
3rd location's NWID: 0xCCCC
4th location's NWID: 0xDDDD
and so forth.
For users whose laptops do not support roaming, a map detailing
the location of each bridge and its associated NWID SHOULD be
provided.
2.6 Multicast
Multicast-based streaming of IETF working group meetings has
evolved considerably over the years. Provisioning of multicast
is straightforward as there is a complete hardware kit brought to
each meeting.
The requirements for multicast are divided into two parts: (1)
network support for multicast transmission, and (2) application
layer support including encoding equipment, cameras, event staff,
etc.
2.6.1 Network support for multicast transmission means the IETF
network SHOULD support PIM-SM, MBGP, and MSDP. The network
MUST ensure there is a feed for the multicast-capable part of
the network into the two multicast rooms. The network MUST use
vendor equipment which supports PIM-SM, MSDP, and MBGP. There
are enough scalability problems with dense mode protocols, that
DVMRP tunnels SHOULD NOT be used. Typically there is enough
N. Bourbaki Expires 2002.12.13 [Page 6]
INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 2002.06.13
local expertise to configure and test multicast without
problem. If help is needed, the IETF technical team is
available.
2.6.2 The work of generating the content to be delivered over the
multicast network has evolved into a fairly stable system. The
current setup is a "traveling IPTV server". Currently, the
University of Oregon provides the encoding hardware for the two
multicast rooms. This hardware is a set of two "refrigerator-
sized" boxes that have a complete set of encoders, cables,
etc., basically, all the necessary hardware. All cameras and
tripods are owned by the IETF and brought to each meeting.
In terms of personnel, the two senior engineers who run the two
channels are currently supplied by the IETF engineering
community. The IETF engineering community coordinates the
volunteers who control cameras and monitor operation during
stable periods. If the local host is interested in adding
local volunteers, this should be coordinated through the IETF
technical team.
2.7 Cabling
IETF networks have been crippled when very long ad hoc fiber runs
have been inadvertently smashed by workfolk and others, and no
spare cable was available. Spares should be kept, and it might
be advisable to mark the runs with caution tape (so users know
where to kick), etc.
3. Network Services
A lot of stress is put on DHCP, printing, and everything else.
3.1 Network Outlets
Laptop users outnumber users needing desktop platforms.
Currently one terminal room 10baseT Ethernet laptop drop per 15
attendees is comfortable. 10baseT Ethernet (e.g. RJ-45
connector) is sufficient, as 10base2 Ethernet has essentially
disappeared, particularly in the laptop computer community.
3.2 DHCP Service
A very wide range of DHCP clients are in use within the IETF
community. The DCHP server SHOULD be widely interoperable and
fully conformant to the DHCP standards [RFC-2131, RFC-2132].
Specifically, a WIDE DHCP or an ISC DHCP server running on a UNIX
platform is strongly recommended until other DHCP servers have
N. Bourbaki Expires 2002.12.13 [Page 7]
INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 2002.06.13
demonstrated better compatibility and standards-compliance. The
IP address pool MUST be large enough to avoid shortages given
constant connection churn.
Repeated experience indicates that it is desirable to have a
sufficiently large pool on standby to permit rolling over DHCP
servers without making a mess. The Internet Registries have a
temporary Class B (or equivalent) address that may be used if
they are asked nicely. Of course it has to be registered routed
to the WAN.
The DCHP server will likely have to serve multiple subnets. This
will also require router configuration.
The DHCP lease timeout must be set short enough to roll over
leases quickly (where 'quickly' is relative to the address space
available for the pool) while not overwhelming the network with
renewal requests. A lease lifetime of one hour appears to work
well if address space is short. A lease lifetime of days can be
used if there is a large free address pool. Too long a lease
time followed by address pool shortage has been a problem at past
meetings. It is important that the DHCP server normally renew
DHCP leases and give out the same IP address to a given node as
long as that node continuously renews its DHCP lease in a timely
manner. This avoids loss of existing network sessions due to
unexpected and needless change of the host's IP address by the
DHCP server. Moderation in all things.
Support for IPv6 DHCP has been provided but seldom used. It is
appreciated by the (very few, if any) IPv6 users.
3.3 Static IP Addresses
A pool of IP addresses for static assignment to laptop users
without DHCP is necessary for approximately one client per 20
attendees. We do not know why that number is so high. There
SHOULD be a mechanism at the help desk to allocate and register
their use.
Providing for allocation by email before the meeting is kind to
those who need to configure security parameters with their normal
home/corporate network prior to the meeting. The static IP
allocation process SHOULD be announced to the IETF Announce
mailing list well before the meeting.
For static allocation at the meeting venue, pieces of paper have
been used. Allocation using 'pegs' [RFC-2322] is an alternative
mechanism which has been used successfully in RIPE and other
N. Bourbaki Expires 2002.12.13 [Page 8]
INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 2002.06.13
meetings for some years.
3.4 Printing
Printer services are very like those in a small computer center.
Two paper printers SHOULD be provided, and a third for spare is
advisable. The printing rate is about .05 PPM / attendee, and a
typical attendee prints approximately 15 pages during the
meeting.
At a recent meeting, the desktop terminal room printer used twice
the amount of paper than the laptop room (which was twice the
size). This suggests that people who bring laptops don't print
as much, copying documents to hard drives instead.
One transparency printing facility MUST be provided. The
transparency printing rate is about .01 PPM / attendee, and a
typical attendee prints approximately 1.5 pages during the
meeting.
A reasonable alternative to a transparency printer is a copier
machine with transparencies loaded. Such a copier SHOULD be
clearly marked as being loaded with transparencies, lest someone
erroneously attempt to use it to create paper copies.
Network printers provided in the terminal room MUST provide BSD
lpd, and PostScript level-2 support. It is helpful to indicate
in advance whether the printers will be supporting standard A4
paper or the strange but patriotic American 8.5x11 inch paper.
Many laptop users are running some version of UNIX. It is
helpful if these users can print documents without resorting to
proprietary printing protocols. Accordingly, at least one
printer that supports the BSD Line Printer (LPR) protocol
[RFC-1179] SHOULD be provided. Configuration parameters for this
printer SHOULD be posted in the terminal room.
Deployment or use of the Internet [sic] Printing Protocol (IPP)
is negligible, so supporting this is purely optional. Absence of
IPP support is unlikely to create a furor among the IETF user
base.
Non-printer transparencies MUST NOT be available near the
printers, or someone will put them in a printer and ruin it.
Macintosh and MS-Windows systems need a print spooling server,
either Samba-based or NT-based. A Samba-based approach will
facilitate the use of the same printers for users of any OS and
N. Bourbaki Expires 2002.12.13 [Page 9]
INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 2002.06.13
has worked well in the past.
3.5 Transparencies
The cost of transparencies and their tendency to jam printers
often warrants manual queue operation. It is kind to train a
local and a nocturnal denizen or two in queue-running to reduce
whining at three in the morning.
3.6 Mail Service
A local SMTP server SHOULD be available for those whose home
servers will not do mail forwarding for clients with strange DNS
names and/or unknown addresses. This server MUST be configured
to accept SMTP relay only when the source IP address is within
the IETF LAN address space, as the IETF does not wish to
contribute to SPAM.
3.7 Time Service
An increasing number of users are running either NTP [RFC-1305]
or SNTP [RFC-1769] on their laptops. A local NTP server SHOULD
be available to serve ntpdate requests for users and to chime
with locals who run NTP clients. The NTP parameters SHOULD be
clearly documented in the terminal room. A UNIX ntpd daemon is
strongly recommended.
3.8 Domain Name Service
At least two local DNS servers MUST be available to users.
Caching DNS servers are preferred. The IP addresses of these
servers MUST be posted in the terminal room and SHOULD be
included in the terminal room documentation supplied in the
registration packet.
3.9 Server Load Considerations
Consider splitting the UNIX server functions over more than one
machine. Print spooling or X duty may bog down a single server.
Consider one server for print queue and Xhost, another for DHCP
and SMTP relay, and a third for NTP and DNS. Isolate the
critical and non-critical server functions on different machines
so a non-critical function, like print queuing, if it stalls or
hangs the machine, won't stop DHCP and DNS.
N. Bourbaki Expires 2002.12.13 [Page 10]
INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 2002.06.13
3.10 Web Proxy/Cache
As noted later, it is helpful to have all of the IETF RFCs and
Internet-Drafts archived on a local server. Ideally this is
accessible via http and also ftp.
In some situations, performance can be boosted by providing a web
proxy cache. If one is used, it is preferred that it NOT be of
the 'transparent web cache' variety, due to concerns about the
compatibility of such devices with all forms of web-based
content. If a 'transparent web cache' will be used, this MUST be
disclosed to users via the IETF Announce list prior to the
meeting. It is reasonable to configure web browsers on the
provided desktops to use the web proxy by default, provided users
are able to disable this manually if needed.
3.11 Help Desk
The help desk SHOULD be staffed from early morning to late
evening by people of patience and clue. As many attendees are
rather experienced, their questions can be rather technical. Of
course, like the typical user population, they also have less
sophisticated needs and temperaments. An emergency contact
number SHOULD be available when the help desk is not staffed.
3.12 Office Supplies
A small stash of office supplies such as staplers, tape, markers,
etc. is often much appreciated. It has been suggested that a
lively market could develop in RJ4x adapters, RJ11 kits, AC plug
converters, local phone to RJ11 adapters, etc. Small ethernet
hubs have also proven useful for network debugging, etc.
3.13 Advanced Technology
While it is tempting for a host/vendor to show off fancy
technology at an IETF, this audience runs and uses the most
arcane assortment of services, and is a very poor place to find
out that your fancy new switch breaks when someone tries to run
IPv42 through it. Run a simple production network. If one must
run a technology demo, isolate it onto a separate network segment
so that it is unable to interfere with the production network.
3.14 Failed Technology
Two attempts have been made to use ATM LAN Emulation, aka LANE,
as the primary backbone protocol connecting all ethernet switches
and routers at IETF meetings. Both attempts were disasters.
N. Bourbaki Expires 2002.12.13 [Page 11]
INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 2002.06.13
Some have asserted that IETF traffic patterns are unusually
unsuited to LANE. You MUST NOT try to use LANE.
4. Computer Systems
Some users prefer UNIX and X11, while others prefer MS-Windows or
Macintosh. Many users are agnostic. But UNIX and Linux bigotry is
increasing. The number of laptops is increasing, and a large number
(circa 20) 802.11b wireless base stations are now regularly available
for IETF meetings. So the need for supplied desktop systems seems to
be declining markedly.
Its preferred that the terminal room support multiple platforms,
though there have been successful terminal rooms with only one system
or the other. Macintosh users tend to being their own systems and so
Mac systems need not be supplied in the terminal room. Some folk
need commercial tools (MS-PowerPoint, StarOffice, WordPerfect, etc.)
to prepare presentations.
Approximately one workstation per 40 attendees is more than adequate.
The percentage of laptop users within the community has continued to
increase to the extent that we now believe that approximately one
desktop system per 30 or more attendees is sufficient. Some months
before the meeting, the IETF Secretariat gives the local host an
estimate of the number of attendees.
4.1 Desktop Software
All provided desktops need at least the following:
standards-compliant web browser
SSHv1 client
X11 server (i.e. the user/display portion)
Telnet client
FTP client
It is very helpful if the following are also provided:
One-Time Passwords (OTP) [RFC-2289] generator
Adobe Acrobat (PDF) reader
miscellaneous other plug-ins for the web browser
4.2 Presentation Tools
A dozen desktops with presentation software applications SHOULD
be provided for those very few <smirk> working on presentations
at the last moment in full panic. These SHOULD have floppy
drives for folk who must use sneaker-net to move files around.
N. Bourbaki Expires 2002.12.13 [Page 12]
INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 2002.06.13
4.3 Environmental
Air conditioning for the entire terminal room SHOULD be
sufficient for the time of year, the heat load from the machines,
and a lot of people.
5. Documentation
As the users' needs mature, so do their expectations of
documentation. It is helpful to document information about the
terminal room and LAN facilities before the meeting on the IETF
meeting web page. A summary should be provided in the registration
packet. Full updated information should be posted in the terminal
room.
5.1 Address Plan
Some weeks before the meeting, the network prefixes (with
netmask) to be used SHOULD be announced on the IETF Announce
list. This allows users with security issues to have their home
networks adjusted if necessary.
5.2 Handout
A single-page document SHOULD be included in the attendees'
registration packets explaining the network layout, addressing,
workstation facilities, printing facilities, LPR parameters, NTP
parameters, SMTP parameters, wireless parameters, et cetera.
5.3 Opening Session
A short presentation on the terminal room and wireless LAN
arrangements is usually given by the local host at the opening
session.
5.4 IETF Documentation
A full on-site mirror of the RFC and I-D directories will lower
demand on the circuits as well as the associated servers. The
address of the mirror should be stated loudly in all
documentation. It is also helpful to post this in the terminal
room. An ftp-accessible or http-accessible on-site repository is
desirable, even if one is using a caching web proxy of some sort.
6. Security Considerations
As in most computer facilities, physical as well as network security
is important.
N. Bourbaki Expires 2002.12.13 [Page 13]
INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 2002.06.13
6.1 Physical Security
Physical security is difficult, with attendees walking in and out
with laptops and other gear at all hours. The guards SHOULD be
told to expect strange things, but to not let large equipment
walk out without a green badge. Equipment has been "lost" in the
past just before, during, or just after an IETF.
Secure on-site storage for boxes and equipment makes life a lot
easier.
6.2 Network Security
Network security is traditional, see the Site Security Handbook
[RFC2196]. The IETF network has been attacked from the outside a
number of times. The risk of attack on the IETF network seems to
rise over time. The IETF network SHOULD be configured to perform
source IP address filtering in accordance with [RFC-2267]. Any
SMTP servers configured with mail relay enabled, SHOULD disable
relaying from outside the IETF network. Enabling MD5
authentication of any routing protocols in use (e.g. RIPv2,
OSPFv2, BGP4) is recommended to reduce risk of a routing-based
attack.
There have been exciting incidents where laptop users have
inadvertantly run DHCP servers, started forwarding packets on the
same wire, etc. If each computer drop (desktop or laptop) is on
its own switched port, it aids in both finding the culprit and in
rapidly reconfiguring for damage mitigation. It can be helpful
if the switches have port filtering and RMON capabilities.
It is believed that written warnings to users against these
dangerous configurations are both prudent and ineffective.
7. Prudence
Spares of all critical components, workstations, switches, routers,
etc. SHOULD be on-site. "A fool and their data are soon parted." --
M Williams
8. References
[IEEE-99a] IEEE, Information Technology -- Telecommunications and
information exchange between systems -- Local and
metropolitan area networks Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY)
specifications. ISBN 0-7381-1658-0, 1999.
N. Bourbaki Expires 2002.12.13 [Page 14]
INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 2002.06.13
[IEEE-99b] IEEE, Information Technology -- Telecommunications and
information exchange between systems -- Local and
metropolitan area networks Part 11: Wireless LAN Medium
Access Control (MAC) and Higher-speed Physical Layer (PHY)
extension in the 2.4 GHz band, ISBN 0-7381-1809-5, 1999.
[JARGON] E. Raymond (Editor), The New Hacker's Dictionary, MIT
Press, September 1996. ISBN 0-262-68092-0. Also,
http://www.tuxedo.org/~esr/jargon
[RFC-1179] L. McLaughlin, Line Printer Daemon Protocol, RFC-1179,
August 1990.
[RFC-1305] D. Mills, Network Time Protocol version 3, RFC-1305, March
1992.
[RFC-1769] D. Mills, Simple Network Time Protocol (SNTP), RFC-1769,
March 1995.
[RFC-2131] R. Droms, Dynamic Host Configuration Protocol (DHCP),
RFC-2131, March 1997.
[RFC-2132] S. Alexander & R. Droms, DHCP Options and BOOTP Vendor
Extensions, RFC-2132, March 1997.
[RFC-2196] B. Fraser, Site Security Handbook, RFC-2196, September
1997.
[RFC-2236] B. Fenner, Internet Group Management Protocol version 2,
RFC-2236, November 1997.
[RFC-2267] P. Ferguson, Network Ingress Filtering: Defeating Denial
of Service Attacks which employ IP Source Address
Spoofing, RFC-2267, January 1998.
[RFC-2289] N. Haller, A One-Time Password System (OTP), RFC-2289,
February 1998.
[RFC-2322] Management of IP numbers by peg-dhcp. K. van den Hout, A. Koopal,
R. van Mook, RFC-2322, April 1998.
[RFC-2460] S. Deering & R. Hinden, IP version 6 Specification,
RFC-2460, December 1998.
[RFC-2461] T. Narten et alia, Neighbor Discovery for IPv6, RFC-2461,
December 1998.
[RFC-2462] S. Thomson & T. Narten, IPv6 Stateless Address
N. Bourbaki Expires 2002.12.13 [Page 15]
INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 2002.06.13
Autoconfiguration, RFC-2462, December 1998.
[RFC-2463] S. Deering, Internet Control Message Protocol for IPv6,
RFC-2463, December 1998.
9. Acknowledgments
The author is indebted for very constructive contributions by a
number of IETF local hosts, the IETF Secretariat, a NANOG local host,
some operators of large networks, a Dutch geek, an amateur linguist,
and of course Mr. (sorreeee) Wireless.
10. Author's Address
N. Bourbaki
666 Rue le Jour
Sophia-Antipolis
nbourbaki@ops.ietf.org
11. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
12. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
N. Bourbaki Expires 2002.12.13 [Page 16]
INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 2002.06.13
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
N. Bourbaki Expires 2002.12.13 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-24 04:18:29 |