advanced networking information

8/6/2019 Advanced Networking Information

1/22

Advanced Networking Information1

Alan Crosswell2

Columbia University Academic Information Systems

March 21, 2000

1http://www.columbia.edu/acis/networks/advanced/2mailto:[email protected]
mailto:[email protected]://www.columbia.edu/acis/networks/advanced/


2/22

2


3/22

Contents

1 Introduction 5

2 Multimedia Applications: Network Audio and Video; IP Telephony 6

2.1 Conferencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 H.323 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.2 Litton CAMVision2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.3 Mbone Conferencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.4 The Access Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Native IP Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 IP Telephony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Performance: Tuning and Quality of Service 10

3.1 TCP Performance Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Quality of Service: Limits as well as Promises . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 Web Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4 Network Performance Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Network: Protocol-Independent Multicast, Routing, Mobility and Wireless Ethernet 12

4.1 Protocol-Independent Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.3 Mobile Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.4 Wireless Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.4.1 IEEE 802.11(b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.4.2 Applications of 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.4.3 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.4.4 Limitations and Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.4.5 Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.5 The Gigabit Core Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.5.1 Switched 10baseT Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.5.2 Switched 100baseTX Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.5.3 Gigabit 1000baseFX Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Security: Firewalls, Detection, and Encryption 16

5.1 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.2 Intrusion Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.3 Encryption: Kerberos, SSH, SSL, IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3


4/22

5.4 Participation in the Internet Security Community . . . . . . . . . . . . . . . . . . . . . . . 17

6 Middleware: LDAP, DNS, and PKI 19

6.1 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.2 Dynamic DNS and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.3 Public Key Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

7 References 21

4


5/22

Chapter 1

Introduction

Columbia University Academic Information Systems1 designs and operates the Universitys internet. An

attempt to cover topics beyond those of basic Internet connectivity2 is made in this document. These topics

include issues regarding high performance networking, new and emerging network protocols and applica-

tions, and several works in progress for your information.

1http://www.columbia.edu/acis2http://www.columbia.edu/acis/networks

5
http://www.columbia.edu/acis/networkshttp://www.columbia.edu/acis


6/22

Chapter 2

Multimedia Applications: Network Audio

and Video; IP Telephony

With the increased available network bandwidth provided by switched LANs (see 4.5) and PCs that can

easily handle the computational demands of video compression, high-quality networked desktop audio andvideo have become feasible.

There are two major classes of video applications. Conferencing is characterized by low-latency highly

interactive communication among a small number of endpoints. Streaming is typically used for one-way

broadcasting of a live or pre-recorded event to a potentially large number of viewers. Interactivity is low or

non-existent so higher latency caused by more computationally-intensive compression or slower hardware

is possible.

2.1 Conferencing

2.1.1 H.323

Two-way or multi-way video conferencing has moved from the domain of expensive dedicated ISDN-based

solutions using the H.320 protocol sending traffic at rates of 128 to 768K to H.323 IP-based systems running

at speeds up to 768K. H.323 implementations are available as software/hardware upgrades or add-ons to

H.320 equipment and as native desktop PC software or add-in hardware implementations. The systems

using H.323 that have been installed and experimented with by AcIS and others in the campus Network

Video User Group1 include:

a Tandberg2 Codec 5000 traditional ISDN (T1) large room system coupled with a RADvision VIU-

3233 H.320-H.323 transcoder,

a Zydacron4 COMcenter PC-based small conference room system,

a Zydacron Z.340 PC-based personal desktop system, and

an Intel Proshare5 PC-based personal desktop system.

1https://www1.columbia.edu/sec/acis/netvideo/2http://www.tandbergusa.com3http://www.radvision.com/products/viu.html4http://www.zydacron.com5http://www.intel.com/proshare/

6
http://www.intel.com/proshare/http://www.zydacron.com/http://www.radvision.com/products/viu.htmlhttp://www.radvision.com/products/viu.htmlhttp://www.tandbergusa.com/https://www1.columbia.edu/sec/acis/netvideo/https://www1.columbia.edu/sec/acis/netvideo/


7/22

Low-end H.323 software-only PC-based systems such as Microsoft Netmeeting and White Pines CU

SeeMe may turn potential users off to H.323 if they havent seen a higher-quality implementation that today

typically uses a hardware add-in card that performs many of the encoding and decoding functions.

Several schools and departments have installed H.320 ISDN systems, many of which could potentially

benefit from use of the available Internet2 bandwidth to communicate with their peer universities by adding

on H.323 transcoding.AcIS is investigating H.323 infrastructure components that include a gatekeeper, which routes calls

between endpoints, and performs directory and bandwidth management functions. We are testing a Cisco

Multimedia Conference Manager gatekeeper. We intend to test an H.320 to H.323 gateway which would

bridge the ISDN and IP worlds. We also plan to test and acquire a Multi-Conference Unit (MCU), which

permits several parties to participate in a single conference.

We are participating in the Internet2 H.323 video conferencing initiative via NYSERNets Multi Con-

ference Service6: Columbia is a host site for NYSERNet conferences and has the use of NYSERNets MCU

and gatekeeper. Weve participated in the Internet2 mega-conference7 demonstrations run by Bob Dixon of

Ohio State.

2.1.2 Litton CAMVision2

While H.323 is an emerging industry standard (based on some would say a bloated H.320 standard), it is not

the only IP video conferencing solution. AcIS has acquired a Litton Network Access Systems8 CAMVision2

low-latency high-fidelity MPEG-2 codec.

The Litton system, which has widely been deployed in North Carolina to replace a statewide proprietary

full-motion video network, and by several Internet2 schools and UCAID, supports a high quality image (full

700x480 D1 image at 30 fps) at data rates from 4 to 15 Mbps and with latencies as low as 150 ms.

To date, Columbia has used the Litton codec to conference in Ted Hanns from the Internet2 offices in

Ann Arbor for our on-campus Internet2 day9; experiment with the Virginia Tech Internet2 Studio; the Na-

tional Library of Medicine; the North Carolina Research and Education Network; and to link a violin master

instructor from our neighbor, the Manhattan School of Music, to students at the University of Oklahoma

School of Music. In each of these cases, significant network engineering work was required to debug and

tune the network path before 15 Mbps video flowed bidirectionally.

The Litton codec, while IP-based, is in fact still a proprietary system as no standard has yet emerged for

MPEG-2 streaming, although Litton and several other vendors have committed to interoperability10.

2.1.3 Mbone Conferencing

Another video conferencing approach still on the to do list is to experiment with IP multicast (see 2.3)conferencing tools such as vic, vat/rat, and IPTV, which enable multi-party conferences without the need for

an MCU, as the network itself provides the needed multiplexing.

6http://www.nysernet.org/mcs.html7http://www.mega-net.net/megaconference8http://www.netaccsys.com9http://www.columbia.edu/acis/i2

10http://nmc.uakron.edu/mpeg2

7
http://nmc.uakron.edu/mpeg2http://www.columbia.edu/acis/i2http://www.netaccsys.com/http://www.mega-net.net/megaconferencehttp://www.nysernet.org/mcs.htmlhttp://www.nysernet.org/mcs.html


8/22

2.1.4 The Access Grid

The Access Grid11 is an advanced mbone-based video conferencing project that uses large screen displays to

try to make conferencing interactivity less like watching TV and more like in person meetings. The Access

Grid is built primarily from free software components on top of Linux and SGI Unix systems.

2.2 Streaming

Streamed audio or video consists of transmitting a continuous stream of data to a receiver which buffers

some amount of data to accomodate jitter in the network and which then begins playing the stream. AcIS

has run RealNetworks RealAudio and RealVideo servers12 for several years to provide both live and on-

demand video streams. This kind of streaming is typically characterized by multiple simultaneous unicast

streams, one for each viewer, which does not scale well as the aggregate bandwidth required is a multiple of

the number of viewers.

Native IP multicast has not been deployed to date in the commodity Internet and is only partially used

among Internet2 members, limiting current streaming technology to multiple unicast streams and various

broadcast tree13 technologies built explicitly on top of a unicast-only network.

2.3 Native IP Multicast

AcIS has joined the Internet2 multicast backbone, peering with both Abilene14 and the vBNS15 I2 back-

bones, which use the relatively new Protocol Independent Multicast (PIM) in sparse mode. This supersedes

the older mbone DVMRP tunnel system. PIM-SM multicast has been enabled on portions of our new gigabit

network.16 Due to bandwidth and reliability constraints, it can not be enabled on the dwindling number of

older network segments.

To experiment with multicast, weve acquired Ciscos IPTV 3.0 Server, Content Manager, and Viewer,

including an MPEG2 full-D1 encoder. Weve also used the vic and vat/rat mbone tools on Unix hosts. Weve

used IPTV 2.0 with an H.261 encoder for two Earthscape17

conferences in parallel with RealVideo streams.AcIS participates in the Internet2 multicast working group18.

2.4 IP Telephony

Sending voice over the Internet has been pretty well finessed. Making it as reliable and easy to use as

a telephone, even replacing conventional telephones, is one of the goals of voice over IP (VoIP) or IP

telephony. Internet versions of call setup features such as conferencing, forwarding, voice-mail, etc. are in

the process of being developed and standardized. A Columbia contributor to this effort is Professor Henning

Schulzrinne19, who has built prototype hardware and software IP phones and is co-author of the Session

Initiation Protocol (SIP).

11http://www-fp.mcs.anl.gov/fl/accessgrid/default.htm12http://www.columbia.edu/acis/live13http://www.realnetworks.com/rbn/14http://www.abilene.iu.edu/15http://www.vbns.net/16http://www.columbia.edu/acis/networks/gig-bb.html#gigbb17http://www.earthscape.org18http://www.internet2.edu/multicast19http://www.cs.columbia.edu/ hgs

8
http://www.cs.columbia.edu/~hgshttp://www.cs.columbia.edu/~hgshttp://www.internet2.edu/multicasthttp://www.earthscape.org/http://www.columbia.edu/acis/networks/gig-bb.html#gigbbhttp://www.columbia.edu/acis/networks/gig-bb.html#gigbbhttp://www.vbns.net/http://www.abilene.iu.edu/http://www.realnetworks.com/rbn/http://www.columbia.edu/acis/livehttp://www-fp.mcs.anl.gov/fl/accessgrid/default.htm


9/22

At the desktop level, several vendors now market IP telephone instruments which plug into an Ethernet

jack. Some include an integral two-port Ethernet switch to plug the desktop PC into. A next generation of

these phones will soon be shipping that take power from the Ethernet jack as well (assuming the network

hub is able to supply power on wires 7 and 8 our Catalyst 5500 hubs are not but the Catalyst 6500s will).

Wireless IEEE 802.11 Ethernet phones are already available from one vendor (Symbol).

A related goal of VoIP is to replace voice trunk lines between conventional phone PBXs and carriers andpotentially to eliminate large centralized PBXs entirely.

Key factors to successful VoIP implementation will include cost reductions, standardization resulting

in product choices from competing vendors, and quality of service (see 3.2) features that will guarantee

the level of telephone reliability people have come to expect. It will also be necessary for the issue of

battery-backed power to be addressed to fulfill safety requirements met by current conventional telephones.

AcIS is investigating VoIP through participation in a NYSERNet-sponsored multi-school project (in

which Henning Schulzrinne is also a particpant). We will be installing a small number of Cisco IP telephones

and a gateway and will work in conjuction with AIS Communications to evalute these and other VoIP

products.

9


10/22

Chapter 3

Performance: Tuning and Quality of Service

3.1 TCP Performance Tuning

High performance networks require tuning of host computers TCP/IP protocol stacks to use them efficiently.When taking bandwidth-delay product of an end-to-end path into account (for a large file transfer between

a researchers workstation and a remote University or national lab, for example) in setting the TCP window,

large improvements in throughput can be attained. Tools to test and, in some cases, automate this tuning

process can be found at the Distributed Applications Support Team1 Internet2 site.

3.2 Quality of Service: Limits as well as Promises

QoS can mean both limiting bandwidth hogs from taking over the network as well as negotiating bandwidth

guarantees for applications that have specific requirements (such as real-time voice or video streams).With a switched gigabit network, it is easy for even a single 10 Mbps host in a residence hall to use close

to 25% of our entire current commodity Internet bandwidth. As innovative applications such as Napster2

have shown, this can easily become a serious network performance problem. Similarly, that same large file

transfer for the researcher that was performance-tuned above, could monopolize bandwidth on Internet2 or

over one of our more constrained links such as the 200 Mbps microwave path between Health Sciences and

Morningside or the 45 Mbps path between Lamont and Morningside.

Traffic shaping and policing is being investigated and QoS policies are being developed. The Weighted

Random Early Detection (WRED) algorithm can be used to shape TCP flows by inserting random packet

loss into a stream. The TCP algorithm notices this loss and reduces the TCP transmission rate to compensate,

effectively reducing the bandwidth consumed by the flow.

To mark criticial traffic for better-than-average service, the TCP precedence bits can be set by appli-cations (and possibly reset or changed by routers implementing policy) to request differentiated services

(Diffserv). Waited Fair Queueing (WFQ) can be used to sort traffic based on precedence at least as far as

our egress routers go. Internet2-wide QoS is an active research area and includes research into end-to-end

bandwidth guarantees (using RSVP) as well as best-effort approaches using Diffserv.

1http://dast.nlanr.net2http://www.napster.com

10
http://www.napster.com/http://dast.nlanr.net/


11/22

3.3 Web Caching

A popular approach to reducing wasted bandwidth is to run a web cache through which all Internet web traf-

fic is routed. Popular web destinations such as the major .com sites and events such as the Star Wars trailer

can be cached locally, or even in a cache hierarchy. For instance, we have several bandwidth-constrained

links (for example, a 10 Mbps microwave link to the Carleton Arms residence) that could potentially benefit

from a local web caching appliance which might further check a central campus cache which in turn could

join the Internet2 web cache hierarchy.

The IRcache Project3 project has developed the Squid4 web cache. There are also several commercial

caching appliances. Web caching does have problems, however. First, to be effective, all web traffic must

pass through the cache, making it a potential point of failure. Actually getting browsers to use the cache

is relatively simple. If one is willing to hijack web traffic and route it via the cache, users do not need

to configure a proxy. Secondly, the cache must be completely transparent and properly handle (or bypass)

secure sessions (SSL), streamed content and the like.

3.4 Network Performance Monitoring

Besides conventional SNMP-based performance monitoring of the campus networks hubs and routers using

tools such as Cricket5, end-to-end Internet2 performance, including latency and jitter is being measured

using three systems: The Active Measurement Probe6 performs periodic pings and traceroutes between all

sites with installed probes. Routing, latency and jitter are recorded and visualized.

A surveyor7 is installed in the Computer Science department. This system is similar to the AMP, with

the addition that it uses a GPS receiver to perform more accurate end-to-end delay measurements.

A passive monitoring tool, the OCxMON8, uses an optical splitter to monitor all OC-3 or OC-12 traffic.

Columbia has been approved for an OC3mon and we expect to receive it soon.

Intrusive measurement tools such as iperf9 are also used to generate simulated traffic to characterize

network and host TCP stack performance.

3http://ircache.nlanr.net/4http://www.squid-cache.org/5http://cricket.cc.columbia.edu/cricket6http://moat.nlanr.net/AMP7http://www.advanced.org/surveyor8http://moat.nlanr.net/PMA9http://dast.nlanr.net/Projects/Iperf/

11
http://dast.nlanr.net/Projects/Iperf/http://moat.nlanr.net/PMAhttp://www.advanced.org/surveyorhttp://moat.nlanr.net/AMPhttp://cricket.cc.columbia.edu/~crickethttp://www.squid-cache.org/http://ircache.nlanr.net/


12/22

Chapter 4

Network: Protocol-Independent Multicast,

Routing, Mobility and Wireless Ethernet

4.1 Protocol-Independent Multicast

IP multicast has gone through several generations of development. Earlier implementations flooded multi-

cast traffic onto all network segments, irrespective of whether there were any hosts listening. This clearly

did not scale well. The latest multicast protocol, PIM in sparse mode, uses a subscription model to build and

prune multicast distribution trees. PIM-SM, coupled with modern multicast-aware level-2 Ethernet switches

permits high bandwidth multicasting that has little or no impact on non-multicast group members.

We have established a PIM-SM rendevous point (RP) for the University on the Internet2 router and

enabled multicast on the gigabit core network and selected subnets as needed. The RP peers with the

Abilene and vBNS multicast RPs to doubly-connect us to the Internet2 mbone.

Understanding and debugging IP multicast is still a black art practiced by members of the Internet2

multicast working group who we are learning from.

4.2 Routing

Due to our almost all-Cisco network, we use Ciscos EIGRP interior routing protocol for the campus net-

work. Our three egress routers (commodity Internet, Internet2, and backup commodity Internet) use the

Border Gateway Protocol (BGP) to exchange full routing tables. These full routes are not redistributed

into the core network via EIGRP. Rather, a default route preference to use the commodity Internet router

is used, which in turn forwards traffic to the Internet2 router. We have found some performance problems

for high-bandwidth Internet2 streams that must take this extra hop and will likely begin redistributing all

Internet2 routes (about 2,000) into the IGP as this will provide best routing for the high-performance users

without an overly large overhead. Currently, we configure static routes for I2 networks as needed to resolve

performance problems (as seen, for example, with the Litton codecs).

4.3 Mobile Networking

To date, mobile networking at Columbia consists of large numbers of public 10baseT Ethernet jacks in

locations such as Butler Library and Lerner Hall. DHCP servers assign dynamic IP address to machines

with pre-registerd MAC addresses. IP Mobility in which ones home system IP address is tunneled across

the network is on the long list of things to look at, but unlikely to be pursued further for the time being.

12


13/22

4.4 Wireless Ethernet

4.4.1 IEEE 802.11(b)

Inexpensive wireless networking has captured many peoples imaginations. There have now been several

generations of wireless networking technology implemented, including several mostly proprietary low and

high-speed solutions, ranging from 14K to 10Mbps, including dialup modem-like cellular phone-basedsystems, medium speed and commercial offerings based on proprietary technologies that are found primarily

in venues used by business travellers such as airports. Of interest to our community are the higher-speed

Ethernet-like products. These include Proxims Symphony and several other products based on frequency

hopping or direct sequence spread spectrum (FHSS, DSSS).

The latest products are now standardized by IEEE 802.111(b) which defines DSSS signalling in the

FCC license-free 2.4 GHz Industrial, Scientific, and Medical band (ISM) at signalling rates of 11 Mbps with

automatic fallback to lower rates of 5.5 and 2 Mbps under adverse conditions. For the user, this is essentially

equivalent to a conventional 10 Mbps wireless shared half-duplex Ethernet.

Higher-performance spread-spectrum 50100 Mbps full-duplex Ethernet in the 5.8 GHz ISM band will

soon be standardized as well. Pre-standards (proprietary) products are available today or expected soon from

several vendors.

4.4.2 Applications of 802.11

We have begun experiments with 11 Mbps IEEE 802.11(b) equipment including the Lucent Wavelan2 PC

cards, Access Points (bridges) and WaveAccess Remote Office Routers and similar products manufactured

by Aironet3, a recent Cisco acquisition.

4.4.3 Applications

Applications we envision for 802.11 include:

Laptop access in lecture halls or multipurpose spaces where wired jacks are not installed.

Outdoor access on the Low Plaza and other public spaces for laptops and PDAs.

Rooftop point-to-point links for outlying buildings in lieu of leased telco circuits. These links could

potentially include the 5.8 GHz 100 Mbps full-duplex products, rather than our current licensed 23

GHz microwave facilities.

Temporary point-to-point links to route around cable cuts.

Neighborhood residential access.

Individual personal installations in offices and residences.

4.4.4 Limitations and Concerns

Wireless Ethernet deployment raises some concerns that must be addressed:

1http://grouper.ieee.org/groups/802/11/index.html2http://www.wavelan.com3http://www.aironet.com

13
http://www.aironet.com/http://www.wavelan.com/http://grouper.ieee.org/groups/802/11/index.html


14/22

Bandwidth A wireless LAN is a shared network, limiting throughput. The net result is that, in areas

where there are a large number of active wireless users, throughput will be much lower than that

for wired switched 10 Mbps Ethernet. It is possible to have as many as three independent 2.4 GHz

WLANs overlap in the same area by using different radio channels, boosting net througput to 30

Mbps. Microcell techniques using antennas that have a short range, with more dense packing of cells

can be used to reduce the number of users in a single cells footprint.

Broadcast Protocols that broadcast a lot of traffic, specifically Novell IPX, will clutter up most of the

WLANs bandwidth with SAP announcements. This and the goal of reducing broadcast in general

motivates for routed rather than bridged WLANs. This contradicts the desire to enable easy roaming

by bridging several cells into a large WLAN subnet.

Eavesdropping and key management. Wireless Ethernet can be spied on by others in the cell. This can be

circumvented by using the encryption features of the 802.11 standard to some extent, except that all

legitimate members of the WLAN can still spy on each other since they all share the same enycryption

key. (Management of those keys with current products would be cumbersome at best.) Use of link-

level encryption for rooftop point to point links is workable, but the correct approach for laptops is of

course host-based encryption using SSL, SSH, Kerberos, IPSEC, etc.

Drive-by networking. Unless encryption is used, or Access Points use some sort of login method, then any

random individual with a laptop and 802.11 card can sit near campus and join the network. Our DHCP

servers will not assign an IP address to an unregistered device, but any user can statically configure

an address. This problem exists today as well for wired Ethernet jacks in public spaces that are not

physically secured. The WaveAccess Remote Office Router is reputed to implement RADIUS access

control in a proprietary manner, and an IEEE standard is under development that will do this for all

Ethernet-like access devices (DSL and cable modems, wired and wireless Ethernet hubs, etc).

Interference and Overlap. The unlicensed nature of part 15 devices offers great flexibility in deployment

but also offers no protection against interference. The 2.4 GHz ISM band has many other FCC-

authorized emitters such as microwave ovens, cordless phones, short-haul consumer video links andof course individually-owned 802.11 consumer producs such as the Apple Airport. Any of these,

when not frequency-coordinated with the official wireless infrastructure have a potential for RF

interfence as well as confusion caused by users PCs associating with random other users personal

access points.

The Apple Airport The Airport is an extremely affordable 802.11 access point that permits wireless access

to a modem or wired Ethernet. Unfortunately, out of the box, the Airport acts as a free love DHCP

server, parceling out unroutable IP addresses to all comers. This behavior can be modified, but will

require user education and likely several cases of denial of service to other users.

4.4.5 CostsIEEE 802.11(b) PC cards are available today in the $150 price range and even lower for Apples product.

Access points are in the $7001500 range depending on features such as bridging vs. IP routing. The Apple

Airport, with equivalent 802.11(b) functionality (it is actually a Lucent Wavelan AP in an Apple wrapper)

is available for around $300. It is limited to a built-in antenna but adds 56K modem support and is targeted

at the personal home and small office wireless market.

Costs to build a functional wireless infrastructure are of course much higher than these component costs.

For each access point, electrical power, a wired network jack, physical security, and aesthetic camouflaging

14


15/22

are needed. This could easily add several thousand dollars per access point. One of the advantages of the

forthcoming line-power standard for RJ-45 wired Ethernet jacks, which is primarily aimed at the Ethernet

telephone market, is that this same power could operate wireless access points, eliminating the cost of AC

power runs.

The 5.8 GHz 100 Mbps products currently run in the $45,000 price range per rooftop device. This is

comparable to conventional 23 and 38 GHz licensed microwave equipment but has the added benefit (andrisk) that, being an unlicensed service, frequency coordination and FCC licensing are not required.

4.5 The Gigabit Core Network

The campus network backbone consists of a dual-star topology gigabit Ethernet core that interconnects

aggregating edge routers that collect gigabit uplinks from building switched Ethernet hubs. Read more

about the new gigabit core network here.4

4.5.1 Switched 10baseT Ethernet

The new network provides a baseline 10baseT switched Ethernet with switch-level support of serveral layer

2 features including 802.1q virtual LANs and snooping of IP multicast group joins and leaves (which extends

the multicast tree branches to only group member desktops.

4.5.2 Switched 100baseTX Ethernet

If category 5 wiring is installed, one may upgrade to 100baseT full-duplex Ethernet. As the network is

centrally funded at the 10baseT level, users must pay the difference in one-time hardware costs to upgrade.

This difference reflects a per port cost reflected by current lower port density on 10/100 line cards vs. 10-

only cards.

4.5.3 Gigabit 1000baseFX Ethernet

100baseFX and 1000baseFX fiber-optic connections to school or departmental LAN switches or routers is

also available at cost. These uplinks will be into the gigabit network edge switch/routers (Catalyst 6509 with

MSFC router board) as is each building Catalyst 5000 switched hubs.

4http://www.columbia.edu/acis/networks/gig-bb.html#gigbb

15
http://www.columbia.edu/acis/networks/gig-bb.html#gigbb


16/22

Chapter 5

Security: Firewalls, Detection, and

Encryption

Maintaining security of servers on the University network continues to be a problem for central and depart-

mental system administrators. The most common attacks include use of open mail relays to act as spamamplifiers and breaking security on a CU host in order to use it to launch attacks against other Internet

sites. Weve also recently seen attempted (and succesful) destruction of individuals files. End-user desktop

viruses continue to be a problem as well, but not something that can be addressed at the network level.

5.1 Firewalls

Running a firewall centrally at the Internet/University border would not be a good solution because the

granularity is too great at this level. Many potential sources of attack (residence halls, public computer

facilities, poorly-run departmental LANs) would be behind the firewall.

The best security is host-based, assuming that even the LAN can not be trusted. The problem is over-

worked or inexperienced system administrators fail to stay on top of administering host-based security.Some school and departmental LAN administrators have implemented or are considering using a firewall to

avoid having to secure individual hosts. This approach can only work if there are clearly defined policies and

methods of identifying who and where the insiders and outsiders are. Firewalling a LAN and then opening

it up for access to several ISPs to let faculty in from home via non-encryption-protected access methods

means the firewall has become nothing more than an expensive sieve. Encryption-protected access tools are

available and used at Columbia (see 5.3).

Those wishing to run a firewall can still use the central campus network rather than installing their own

wiring and hubs. AcIS will configure a non-routed virtual LAN to which the departmental firewall attaches

in addition to attaching to a routable LAN.

AcIS is acquiring a PIX firewall and administration tools from Cisco to be able to better advise depart-

ments on firewall features and options. We will compare the PIX to freeware solutions using a Linux system

with ipchains1, for example.

5.2 Intrusion Detection

Host-based intrusion detection systems notice attempts at access to the given host that is somehow unusual.

This may include listening on network ports that are not normally active on the given host for the express

1http://www.rustcorp.com/linux/ipchains/

16
http://www.rustcorp.com/linux/ipchains/


17/22

purpose of catching port-scanning attempts. Besides denying access, these devices log the attempt and some

overworked sysadmin has to respond to these logs(!). More advanced intrusion detection systems might

correlate attempts against several hosts to identify a coordinated or network-scanning attack and might

take automated action such as blocking further network access from the offending host or network. Traffic

analysis could also be used to detect levels of traffic that cross some firewall in the campus that are unusual.

For example, reviews of the top ten IP flows are currently performed periodicially to find what are frequentlyabusers of the network. Active good guy port-scanning is used to help find hosts that would be broken

into had a port-scan been performed against them.

AcIS has not invested in commercial automated intrusion detection products but does heavily use TCP

wrappers, automated auditing and summarization of security logs, and periodic IP flow reviews, as well

as responding to specific abuse complaints. We periodically scan the residence halls network and notify

students of hosts that have been found to be insecure or already broken into.

5.3 Encryption: Kerberos, SSH, SSL, IPsec

Frequently, especially on older shared network hubs here or at remote sites, network sniffers are installed

which capture user passwords or other data. Host-based encryption software that defeats sniffing and othermore sophisticated replay and spoofing attacks has been available for years and is used by a small percent-

age of the University community. We are not quite there yet but hope to soon completely disallow clear

text passwords for telnet, imap, pop, and ftp, making encrypted authentication and possibly full session

encryption mandatory. These capabilites are available today:

Kerberos We have been operating a large Kerberos IV realm for many years. In December 1999 we up-

graded to a Kerberos V realm which is largely operating using Kerberos IV compatibility. Logins on

CUNIX, secure web servers, imap and kpop servers either use Kerberos protocols directly or proxy a

Kerberos authentication. In many cases, the proxied Kerberos authentication still passes the password

in cleartext as we have not yet disabled all non-encrypted access.

SSL Secure Session Layer is used on our secure web servers (https) to perform end-to-end session en-cryption. Web logins are tunelled through SSL to invoke an Apache module that proxies Kerberos

authentication.

SSH Secure Shell version 1 servers are installed on all CUNIX hosts. A a result of Datafellows new

university licensing policy, SSH version 2 servers will be made available soon.

IPsec We are at the early stages of learning about the various IPsec options and how we might implement

them. The PIX firewall can terminate IPsec tunnels and Windows-2000 and Solaris 8 include native

IPsec support. We need to understand and implement the significant key management services (see

6.3).

5.4 Participation in the Internet Security Community

In the early 1990s AcIS staff participated in a joint ColumbiaPresbyterian network security research

project2 that resulted in the Universitys network user authentication and authorization architecture3 that

today enables secure web access by tens of thousands of Columbia community members to hundreds of

2ftp://ftp.columbia.edu/cpsec3ftp://ftp.columbia.edu/cpsec/nua.pdf

17
ftp://ftp.columbia.edu/cpsec/nua.pdfftp://ftp.columbia.edu/cpsecftp://ftp.columbia.edu/cpsec


18/22

secure web services such as Student Services Online4, bulletin boards5, and others. Our participation in a

joint Columbia-Presbyterian policy project resulted in the current University information security policy.

More recently, the Kermit project6 has worked with MIT and others to add Kerberos authentication and

encryption to Kermit and has worked in the IETF Common Authentication Technology7 working group. We

are also represented on the Internet2 Security Working Group.

Prototype implementations of public key cryptography-based systems for inter-organizational authoriza-tion have been piloted with several members of the Digital Library Federation8.

4https://www.ais.columbia.edu/cgi-bin/ssv/ssol5https://www1.columbia.edu/sec/bboard6http://www.columbia.edu/kermit7http://www.ietf.org/html.charters/cat-charter.html8http://www.dlib.org/dlib/november99/millman/11millman.html

18
http://www.dlib.org/dlib/november99/millman/11millman.htmlhttp://www.ietf.org/html.charters/cat-charter.htmlhttp://www.columbia.edu/kermithttps://www1.columbia.edu/sec/bboardhttps://www.ais.columbia.edu/cgi-bin/ssv/ssol


19/22

Chapter 6

Middleware: LDAP, DNS, and PKI

We recently participated in the Internet2 Middleware1 projects Early Harvest2 meeting for early adopters

of middleware such as directories and network authentication and authorization services.

6.1 LDAP

Weve been involved in directory efforts for many years, having been a participant in the NYSERNet X.500

White Pages pilot project several years ago. After determining that X.500 was cool but the free software

X.500 implementation (Quipu) was a slow pig, we adopted UIUCs qi/ph (CSNET nameserver) to provide

white pages service.

Weve since completely retired our UIUC qi/ph name service and are now using OpenLDAP servers

(with data fed from a relational database system) for:

1. White pages (people directory).

2. Network authorization service3 (group memberships) used primarily by our secure web servers for

access to course bboards and the like.

3. Replacement for all NIS maps (passwd, etc.) on our Solaris 7 hosts (using locally-developed PAMs

and other software).

4. Web-based user account creation and management.

We are doing active development in hardening the Solaris 7 LDAP implementation which we found did not

scale well in a lab environment of 72 Ultra-10 clients and in implementing real-time LDAP updates which

to date we have not permitted since all our directory services are based on an underlying legacy RDBMS

implementation (we regenerate our LDAP directories nightly).

6.2 Dynamic DNS and DHCP

Weve used dynamicly-updated DHCP service accessed by a secure web page for several years to enable

individuals to register their MAC addresses and receive DHCP service shortly thereafter. DNS updates have

however occurred only nightly since a disruptive BIND reload is required. We are looking at dynamic DNS

1http://www.internet2.edu/middleware2http://www.internet2.edu/middleware/earlyharvest3http://www.dlib.org/dlib/september98/millman/09millman.html

19
http://www.dlib.org/dlib/september98/millman/09millman.htmlhttp://www.internet2.edu/middleware/earlyharvesthttp://www.internet2.edu/middleware


20/22

updates, a feature pushed by Microsofts Windows 2000 Active Directory integration, to possibly enable

realtime DNS updates as well. However, we are also reconsidering what value if any static hostname/IP

assignment plays for the vast majority of client PCs that do not need to be well known.

6.3 Public Key Infrastructure

Weve so far avoided the headache of building a public key management infrastructure for individuals at CU

by using Kerberos, however the time is rapidly approaching where it will be necessary to start rolling out

this service. Motivating factors include IPsec, the work going on in the DLF projects for inter-institutional

authorization, national initialives such as the NIST Public Key Infrastructure program4, and the NET@EDU

PKI for Networked Higher Education5 project.

PKI development will also require significant effort from the Counels and Controllers office in devel-

oping a Certificate Practice Statement.6

4http://csrc.nist.gov/pki/program/welcome.html5http://www.educause.edu/netatedu/groups/pki/6http://www.cren.net/cren/cadocuments.html

20
http://www.cren.net/cren/cadocuments.htmlhttp://www.educause.edu/netatedu/groups/pki/http://www.educause.edu/netatedu/groups/pki/http://csrc.nist.gov/pki/program/welcome.html


21/22

Chapter 7

References

Multimedia Applications

IETF Multiparty Multimedia Session Control Working Group http://www.ietf.org/html.charters/mmusi

charter.html

Interactive MPEG-2 Forum http://nmc.uakron.edu/mpeg2

NGI MPEG-2 Users Forum http://www.NGIforum.org

H.323 Videoconferencing

SURA Video Development Inititative (ViDe) http://vide.utk.edu

Megaconference http://www.mega-net.net/megaconference

NYSERNet Multi-site Conference Servce http://www.nysernet.org/mcs.html

CU Network Video User Group https://www1.columbia.edu/sec/acis/netvideo

AcIS RealVideo info http://www.columbia.edu/acis/live

Performance Measurement & Tuning

NLANR Measurement and Operations Analysis Team (MOAT) http://moat.nlanr.net

TCPtune automated Windows TCP stack tuning http://moat.nlanr.net/Software/TCPtune

Active Measurement Probe (AMP) http://moat.nlanr.net/AMP

Passive Measurement (OCxMON) http://moat.nlanr.net/PMA

NLANR Distributed Applications Support Team (DAST) http://dast.nlanr.net

Iperf active measurement tool http://dast.nlanr.net/Projects/Iperf

NLANR National Center for Network Engineering (NCNE) http://ncne.nlanr.net

Surveyor active measurement http://www.advanced.org/surveyor

AcIS Cricket Graphs http://cricket.cc.columbia.edu/ cricket

Jumbo Ethernet frames http://www.columbia.edu/acis/networks/advanced/jumbo/jumbo.html

Network

Multicast

Internet2 Multicast working group http://www.internet2.edu/multicast

NCNE Multicast FAQ http://www.ncne.nlanr.net/faq/multicast.html

21
http://www.ncne.nlanr.net/faq/multicast.htmlhttp://www.internet2.edu/multicasthttp://www.columbia.edu/acis/networks/advanced/jumbo/jumbo.htmlhttp://cricket.cc.columbia.edu/~crickethttp://www.advanced.org/surveyorhttp://ncne.nlanr.net/http://dast.nlanr.net/Projects/Iperfhttp://dast.nlanr.net/http://moat.nlanr.net/PMAhttp://moat.nlanr.net/AMPhttp://moat.nlanr.net/Software/TCPtunehttp://moat.nlanr.net/http://www.columbia.edu/acis/livehttps://www1.columbia.edu/sec/acis/netvideohttp://www.nysernet.org/mcs.htmlhttp://www.mega-net.net/megaconferencehttp://vide.utk.edu/http://www.ngiforum.org/http://nmc.uakron.edu/mpeg2http://www.ietf.org/html.charters/mmusic-charter.html


22/22

Cisco Systems multicast page ftp://ftp-eng.cisco.com/ipmulticast

Abilene multicast cookbook. www.abilene.iu.edu/index.cgi?page=mc-cookbook

NCNE Multicast Looking Glass http://www.ncne.nlanr.net/tools/mlg2.html

Abilene Multicast Map http://www.abilene.iu.edu/images/ab-mcast.pdf

vBNS multicast stats http://www.vbns.net/stats/mcast

vBNS multicast info http://www.vbns.net/multicast

Wireless IEEE 802.11

Lucent WaveLAN http://www.wavelan.com

Aironet http://www.aironet.com

University Network

Columbia University Network Status http://www.columbia.edu/acis/i2/slides/crosswell.pdf.

Presented at the Fourth Annual Internet2 Joint Techs Meeting1, Miami, 5-8 December, 1999

Internet2 http://www.internet2.edu

Abilene http://www.abilene.iu.edu/

vBNS http://www.vbns.net NYSERNet http://www.nysernet.org

Columbia Internet2 Day http://www.columbia.edu/acis/i2

Security

CU Computer Security info http://www.columbia.edu/acis/security

Middleware

Internet2 Middleware Project http://www.internet2.edu/middleware

Digital Library Authorization and Authentication Architecture http://www/acis/rad/authmethods/dla3/

Web Access Broker http://www/acis/rad/authmethods/broker/

CREN Certificate Authority Documents http://www.cren.net/cren/cadocuments.html

NET@EDU PKI http://www.educause.edu/netatedu/groups/pki/

1http://www.ncne.nlanr.net/news/workshop/1999/991205/

22
http://www.educause.edu/netatedu/groups/pki/http://www.cren.net/cren/cadocuments.htmlhttp://www/acis/rad/authmethods/broker/http://www/acis/rad/authmethods/dla3/http://www.internet2.edu/middlewarehttp://www.columbia.edu/acis/securityhttp://www.columbia.edu/acis/i2http://www.nysernet.org/http://www.vbns.net/http://www.abilene.iu.edu/http://www.internet2.edu/http://www.ncne.nlanr.net/news/workshop/1999/991205/http://www.columbia.edu/acis/i2/slides/crosswell.pdfhttp://www.aironet.com/http://www.wavelan.com/http://www.vbns.net/multicasthttp://www.vbns.net/stats/mcasthttp://www.abilene.iu.edu/images/ab-mcast.pdfhttp://www.ncne.nlanr.net/tools/mlg2.htmlhttp://www.abilene.iu.edu/index.cgi?page=mc-cookbookftp://ftp-eng.cisco.com/ipmulticast