Angelos D. Keromytis
Distributed Systems Lab, University of Pennsylvania
Jason L. Wright
Network Security Technologies, Inc. (NETSEC)
Abstract
Recentworkintheareaofnetworksecurity,suchas
IPsec, providesmechanismsforsecuring the traÆc
betweenanytwointerconnectedhosts. However,it
is not always possible, economical, oreven
practi-calfromanadministrationandoperationalpointof
view to upgrade the software and conguration of
allthenodesin anetworkto supportsuchsecurity
protocols.
Oneapparentsolutiontothisproblemistheuseof
security gateways that apply the relevant security
protocols on behalf of the protected nodes, under
theassumptionthat the\lasthop"betweenthe
se-curity gateway and the end node is safe without
cryptography. Such a gateway can be set to
en-force specic security policiesfor dierent typesof
traÆc. Whilethissolutionisappealinginstatic
sce-narios (such as building so-called\intranets"), the
use of Layer-3 (network) routers as security
gate-wayspresentssometransparencyandconguration
problemswithregardstopeerauthenticationinthe
automatedkeymanagementprotocol.
This paper describes the architecture and
imple-mentationof aLayer-2(link layer) bridgewith
ex-tensions for oering Layer-3 security services. We
extend the OpenBSD ethernet bridge to perform
simple IPpacket lteringand IPsec processing for
incoming and outgoingpackets on behalf of a
pro-tected node, completely transparently to both the
protectedandtheremotecommunicationendpoint.
The same mechanism may be used to construct
\virtuallocalareanetworks,"byestablishingIPsec
tunnels between OpenBSD bridges connected
geo-graphically separated LANs. As our system
oper-orcongurationchangesintheprotectednodes.
1 Introduction
Network bridges are simple devices that
transpar-ently connect twoormore LANsegments by
stor-ing a frame received from one segment and
for-wardingit to the other segments. More intelligent
bridges make use of a spanning tree algorithm to
detect and avoid loops in the topology. We have
implemented the basic form of an ethernet bridge
in OpenBSD that also provides an IP ltering
ca-pability. Thus, the bridge can be used to provide
aLAN-transparentrewallbetweenhostssuchthat
no congurationchanges are needed onclient
ma-chines,andonlyminorchangesinnetworktopology
arenecessary.
For this, we make use of ipf, the standard packet
ltering mechanism available. As ethernet frames
passthrough thebridge, they are examinedto see
if they carry IP traÆc. If not, the frame is just
bridged. IftheframedoescontainIPtraÆc,the
eth-ernetheaderisremovedfromtheframeandcopied.
The resultingIP packet is passedon to ipf, which
notiesthebridge whether thepacket is to be
for-warded or dropped. The ethernet header of the
frameunder examinationis appropriatelymodied
on the frame to be forwarded, and the resulting
frameisthenbridgedasnormal.
Thebridgecanalso beused toenforce restrictions
onwhichaddressescanappearoneachethernet
seg-ment,which helpslocalizewhere ARPspoong
tosendtraÆctothewrongsegment. Theabilityto
learnMACaddressesdynamicallyiscongurableon
eachportofthebridge,andbroadcastdiscoveryfor
machines unknowntothebridgecanbetoggledon
aperport basis. Additionally, amechanismis
pro-vided for lteringethernet frames basedon source
and/ordestinationMACaddress.
Thisfunctionality,usefulonitsown,canbecoupled
with the IPsec [9] support available in OpenBSD,
to allowcreationofvirtualLANs. Thisis achieved
byoverlayinganIPsec-protectedvirtualnetworkon
thewideareanetwork (oreventheInternet itself).
ThechangesnecessarytothebridgeandIPseccode
for this were fairly minimal, due to compatibility
ofsomedesigndecisionsmadeindependentlyinthe
developmentofthetwopackages.
The enhanced bridge can also be used to provide
transparentIPsec gateway capability for ahostor
evenanetwork. Inthis mode,the bridgeexamines
transientIPtraÆcandmay,dependingonsecurity
policy, establish IPsec security associations (SAs)
witharemotehostpretendingtobethelocal
com-municationendpointfor anIPsession 1
. There are
twomain benetsfromthis. First,thisallows
pro-tectionofthecommunicationsofahostornetwork
withoutchangestotheprotectedhosts(whichmay
not even be possible, for old, unsupported, or
ex-tremelylightweightsystems). Second, thesecurity
gateway can act as a security policy enforcer,
en-suringthatincomingandoutgoingpacketsare
ade-quatelyprotected,basedonsystemornetwork
pol-icy.
1.1 Paper Organization
Section 2brieydescribesthebridgeitself andthe
ltering of frames containing IP traÆc. Section 3
describes the use of IPsec in conjunction with the
bridgetobuildvirtualLANsandtransparentIPsec
gateways. Section 4discussesopenendsandfuture
work,andSection5concludes thepaper.
1
Theterm \IP session"is usedhere loosely to implya
packetowbetweentwohosts,oneofwhichisononeofthe
Bridges are devices that operate at the data link
layer, tying together dierent ethernet (or other
LAN) segments. InOpenBSD, thebridgeis
imple-mentedasapseudo-networkinterfaceinsidethe
ker-nel. Realethernetinterfacesareaddedtothebridge
interfaceas\bridge members,"andforthepurpose
ofusingIPsecwiththebridge,encinterfacescanbe
added on asmembers. The enc interfaces contain
thesecurityassociation(SA)forcommunicationto
remoteLANs. InallethernetdriversunderBSD,
re-ceivedframesareassembledintombufs[11],adata
structurethat providesforeasy insertionand
dele-tion of data with little or no data copying. The
ethernetheaderisremovedandpassedalongwitha
reference to the receiving interface and the mbuf
containing the frame data to etherinput(). The
bridge intercepts the frame early in this function,
afterasmallamountofbookkeepingisperformed.
Onentrytothebridgecode,theframeischeckedto
see ifit isabroadcast,multicast, orunicast frame
(Figure 1). Broadcast and multicast frames are
copied and queued on the bridge (so they can be
forwardedin allmemberinterfaces), andthe
origi-nalframeisreturnedtoetherinput(),sothatitcan
be processedby thebridgemachineitself. Unicast
framesarecheckedtoseeifthedestinationmatches
anyoftheMACaddressesofportsonthebridge;if
so, theframe is returned to ether input()for local
processing. If the frame is unicast and addressed
to the bridge machine, the frame is queued and
not passed back to etherinput(). When a packet
isqueued,asoftwareinterruptisscheduledsothat
bridgeprocessingwilloccuroutsideoftheinterrupt
contextoftheethernetcard.
Thebulkoftheframeprocessingoccursinthe
soft-ware interrupthandler,bridgeintr() (see Figure2).
This routine loops through each bridge interface,
pullingframesfromtheirinputqueues. Thesource
ethernet addressand source interface are recorded
intothebridge'saddresscacheforeachframe(after
someaddressspoof-checking). Thedestination
eth-ernetaddressislookedupinthecache;ifthe
inter-facereturnedbythelookupisthesameasthe
inter-facewheretheframeoriginated,nofurther
process-ingisdone. Ifthedestinationinterfacediersfrom
thesource,theframemustbeforwarded(bridged).
If the frame is for a multicast or broadcast
Ethernet Driver
ether_input()
all frames
broadcast and
local frames
bridge_input()
Frame queued,
soft interrupt
scheduled
broadcast and
non-local frames
Ethernet
Layer-3
Protocols
IPsec (enc)
etherip_input()
IPsec
extensions
Figure1: Frameowfromdrivertobridgeandlayer-3protocols.
interfaces with multicast traÆc from fast ethernet
interfaces,itispossibletodisallowmulticastpacket
and/orframeforwardingoverthebridge. Currently,
thisisspeciedforthewholebridge. Inthefuture,
we would like to be able to specify this on a
per-memberinterfacebasis.
2.1 Layer-3 Filtering
Before frames are forwarded, they are ltered by
calling oneof theipfroutineswith theframeto be
processed. This allows for standard ltering rules
to be applied to bridge member interfaces asthey
would befornormal routed rewall. Rules are
ap-pliedto allincomingframes thatcontainIPtraÆc
andareboundtoeachmemberinterface.
The ipfroutines expect an IPpacket to bepassed
to them, but the bridge operatesin terms of
eth-ernet frames. The ethernet header is examinedto
determinewhethertheframecontainsanIPpacket.
Sincetherearetwopossibleencapsulationmethods
for IP over ethernet, both must be examined and
theappropriateamountofheaderinformationmust
becopiedandremovedfromtheframe,leavingthe
IPdataintact. Theresultingpacketispassedtoipf,
whicheitherdropsthepacketorreturnsit. Packets
thatarenotlteredhavetheirethernetheaders
re-attachedandarenallyforwardedasdeterminedby
thebridge. Usingthisapproach,weavoidedhaving
2.2 Layer-2 Filtering
Inaddition to providingIP (Layer-3) ltering, the
bridgeiscapableoflteringpacketsbasedonsource
anddestination ethernetMACaddress. The
lter-ingrulesfollowasyntaxmuchliketheipfrulesand
are applied in the order in which they are added.
Rulescanbeappliedbothasaframeisreceivedby
thebridge(oninput)orbeforetheframeissentout
fromthebridge(output).
The bridge can also be used to block all non-IP
traÆc. A ag on each member interface species
whetherit shouldallownon-IPtraÆc tobepassed
inoroutbasedontheprotocoleldintheethernet
header. Thisallowsframestobeblockedwhenthey
cannotbe lteredbythe Layer-3mechanisms
pro-vided so that tunnelsthroughother protocols
can-notbecreated. Theonlyprotocolsallowedthrough
an interface with this ag are the protocols
nec-essary for IP to function: IPv4, IPv6, ARP, and
RARP.
2.3 Bridge as Normal Host
A machine actingasabridge neednot haveanIP
address. All ofthe lteringprovided bythebridge
andipfcanbehandled in theabsenceofanIP
ad-dress,andthisisactuallyaneasiercasetohandle.
Forthebridgemachineto actasanormalhost,in
addition to its duties as a bridge, several changes
bridgeintr()
Record MAC
source address
Drop same
segment frames
Non-IP
handling
Multicast
handling
Layer-2 filtering
(input)
Layer-3 (IP)
filtering
Individual Frame
Layer-2 filtering
(output)
Queued on
interface 1
Ethernet
OR
IPsec
Layer-2 filtering
(output)
Queued on
interface 2
Ethernet
OR
IPsec
Layer-2 filtering
(output)
Queued on
interface N
Ethernet
OR
IPsec
...
...
...
Figure2: Frameowfromwithin bridgeintr()withLayer-2andLayer-3handling.
areaddressedtoanyofthememberinterfacesofthe
bridgearesimplyreturnedtoether input().
Broad-castandmulticastframesmustbecopied. The
orig-inalframeisreturnedtoetherinput(),andthecopy
isqueuedonthebridge.
For frames sent by the bridge, etheroutput() was
modied to include a special case for interfaces
that are bridgemembersand the frameto be sent
is passed to bridgeoutput(). This function
exam-ines theethernet destination addressof the frame.
For unicast destinations, the bridge address cache
is used to locate the recipient. For multicast and
broadcast destinations, as well as unicast
destina-tions not found in the address cache, the frame is
forwardedtoallmemberinterfacesofthebridge.
As a result of this design, a machine acting as a
bridgecanalsoparticipateontheLANasanormal
host. When,for example,itsendsanARP request
forahost,itwillbeforwardedoutofeverymember
interface. When a reply is received on any
inter-face,thesourceinterfaceand addressareaddedto
thebridge addresscacheaswellasitsARP cache,
and theframeis processedasnormal. Fromthere,
allunicastframestotheremotehostwillusethe
in-formationfromtheaddresscacheforsendingframes
onlyonthecorrectinterface.
2.4 Bridge Security
Asdiscussedpreviously,thebridgeprovidesseveral
methodsforenforcingnetworksecuritypolicy. One
formof internalattackisMACspoongwhereone
ofavictimhost. Thebridgeprovidestwomeasures
for preventing this attack from being completely
successful: Layer-2ltersandstaticaddressentries.
For the Layer-2 lters, the ethernet MAC address
of the potential victim is added to a set of rules.
For thebridge interface onthe segment where the
hostissupposedtobe,rulesareaddedtopermitthe
addressto be thesourceand destination of frames
forinput and output. On theother interfaces, the
address is added to rules blocking it as a source
addressoninputanddestinationaddressonoutput
fromeachinterface.
Additionally, adding a static address cache entry
thatbindstheethernetMACaddressofthe
poten-tialvictim hosttothebridgeinterfaceonthesame
segmentasthehostwillpreventthebridgeaddress
cache from being polluted with invalid data. The
bridge cannot prevent the attack from being
suc-cessful onindividual segments, but it canlimit its
scopein onesegmentonly.
Anotherform ofinternalattack,ARP spoong,
in-volves a host on the network using its own MAC
addressand forgingARP responses claimingto be
anotherhost. ThebridgedoesnottreatARP
pack-ets dierent from other packets, so this attack is
not directly preventable. The attacking host may
beabletoconvincehostsonothersegmentsthatits
ethernet MAC address is the one associated with
theIPaddressvictimhost,but byusing IPlters,
actualIPpacketcommunicationthroughthebridge
Thelteringcapabilitiesoeredbythebridgeallow
itsuseasatransparentpacketlteringrewall. As
wasthe casewithtraditional rewallshowever,
l-tering by itselfisnotsuÆcientin fullling network
security concerns. Network layerencryption,
typi-cally in the form of IPsec, is seeing increasing use
in protecting traÆc between networks, hosts, and
users. Thus, we decided to augment the ltering
bridgewithIPseccapabilities.
ThissectionstartswithabriefoverviewoftheIPsec
implementation in OpenBSD, then describes the
two congurations where bridging and IPsec may
beused together.
Therstof thesecongurations, \virtualLAN," is
usedtotransparentlyandsecurelyconnectethernet
segmentsoverawideareanetwork. Thisisachieved
byencapsulatingethernetframesinsideIPsec
pack-ets which are then transmitted to aremote bridge
thatremovestheprotectionandforwardstheframes
tothelocalLAN.
Thesecondcongurationiswhatthestandardscall
a\bumpin thewire"(BITW) implementation [9],
wherein a security gateway (the bridge)
transpar-ently implements IPsec on behalf of one or more
\protected" hosts. This allows gradual
introduc-tionofIPsecinanetworkwithoutchangingtheend
host conguration orsoftware. This conguration
isalsoacommondesignfeatureofnetworksecurity
systemsused bythemilitary.
Perhapsmoreimportantly,suchatransparentIPsec
gatewaycanbeused to enforce securityproperties
for communications between the protected (or
su-pervised) hosts and therest ofthe world. Packets
traversing the gateway can be examined and,
de-pendingonsystempolicy:
Theymaybeforwardedordropped,similarto
apacketlteringrewall.
Outgoingpacketsmaycausethesecurity
gate-wayto attempt to establisha security
associ-ation(SA) withthedestination host,
pretend-ingtobetheoriginatinghost,ifthepacketsare
unencrypted. Ifthepacketsarealready
IPsec-protected, it could simply forward them (or,
in ourcase,bridgethem). Naturally,the
secu-securitypropertiesofthepacket stream.
Similarly, for incoming packets, the gateway
couldestablish asecurityassociationwith the
originator if the packet was received
unen-crypted and/or unauthenticated, again
pre-tendingtobethedestinationhost.
Finally,thebridgecaninterceptincomingIKE
[5]packetsthatrequestnegotiationwithoneof
the protectedhosts, and perform the
negotia-tionasthathost.
Thus, in the last three cases, thesecurity gateway
acts as a transparent network policy enforcer. A
routing rewall can perform the same functions,
howeverit would have to establish tunnel SAs
be-tween itself and the remote host on behalf of the
protected host. It would do so using its own IP
address, an so would need to \prove" its right to
proxy-IPsec for theend host. While this is trivial
for static congurations, where the identities and
networkaddressesofthetwopeersareknowna
pri-ori, thesituation becomes more complicated when
tryingtodoopportunisticencryption.
The two primary envisioned methods for host
au-thentication areDNSSEC[3]andX.509[2]. Inthe
formercase, thedomain nameserverscansecurely
providethepublickeyassociatedwithahostname
oraddress. Thatkeymay thenbeusedto
authen-ticate the IKE peer. In the X.509 case, a
Certi-cation Authority (CA) infrastructure is assumed
to provide the public key of an end host or user
(the protocolsfor doingsoin alarge-scalenetwork
suchastheInternetarelesswell-denedthanDNS).
Here,the IPaddress ofthe hostassociatedwith a
key is embedded in an X.509 certicate. Ineither
casehowever,itis notimmediatelyclear (and
cur-rentlyundened)howtoexpresstherightofa
re-wall to establish SAs on behalf of a host. While
work has recently started in theIETF IP Security
Policy(IPSP)WorkingGroup,developmentand
de-ployment of a protocol that would allow security
gatewaydiscoveryissomeyearsaway.
3.1 OpenBSD IPsec
IPsecin the OpenBSD kernelis implemented asa
pair of transport protocols [7, 8]. Incoming IPsec
pro-forexample,toTCPorUDP).Notethatonly
pack-etsdestinedforthelocalhostarehandledthisway;
IPsec packets that are passingthrough are simply
forwardedifthehostisconguredtoactasarouter,
otherwisetheyaredropped).
Outgoing packets are intercepted at ip output(),
where acheck ismade to seeif IPsecprocessing is
necessary. Ifso,theappropriateIPsecprotocol
out-put routinesarecalled which encrypt/authenticate
thepacket,andthenre-senditviaipoutput()
speci-fyingthatIPsecprocessinghasalreadyoccurred(so
astoavoidloops). Twomethodsareusedto
deter-minewhetherapacketneedstobeIPsec-processed:
If the packet originated from a local socket,
it may have an attached Security Association
(SA).
If no such information is available,the source
and destination addresses and ports from the
packetareusedtomakealookupinthekernel
SecurityPolicyDatabase(SPD).InOpenBSD,
theSPDisimplementedasanewprotocol
fam-ilyintheradixtree,whichisalsousedfor
rout-ingentries. Thereareseveralbenetsto using
theradixtree:
{ Codereuse (and,thus, bugavoidance).
{ The radix tree internal representation is
compact, allowing for large numbers of
SPDentrieswithouthighmemory
require-ments.
{ Lookup cost scales well with number of
entries inthetable.
{ Becausealookupreturnsthemostspecic
result, it is easy to implement \backup"
entries for packet classes (or, conversely,
wecan havespecial case handlingof
cer-tainpacketclasses).
In both cases, the lookup provides enough
infor-mation to locate theSA. Note that, on input, the
packet itselfcontainsenoughinformationto locate
theSA.TheSA itselfcontainssuchinformationas
the cryptographicalgorithmsand keysto beused,
what optional features of the protocols are in use,
variousexpirationtimers,etc.
BoththeSA andSPDtables maybepopulated
ei-orPhoturis[6]). Theinterfaceto thekernel for
ei-therofthesemethodsisviathePFKEYsocket[14],
which is in many ways similar to theBSD routing
socket.
Both in input or output, if the necessary
crypto-graphic material hasnot been negotiated with the
remoteIPsecendpoint(forexample,whendoing
on-demand or\opportunistic"IPsec),it is possibleto
notify a keymanagement daemon which will then
negotiate and install the proper SA and SPD
en-triesin thekernel.
Wehavealsoimplementedtheencpseudo-interface.
Inputpacketsthat areIPsec-processedaremadeto
appear asiftheywere receivedfromthe enc
inter-face,bychangingtheinterfacepointer inthembuf
header.Thus,anadministratorcaneasilylter
non-IPsec protected packets using any packet ltering
package. Furthermore, utilities like tcpdump [13]
can be used to view the intermediate products of
IPsecprocessing,fordebuggingpurposes(thisonly
works if IPsec processing takes place in the local
host).
A moreextensive (if somewhat dated) overview of
theOpenBSDIPsecarchitectureis givenin[10].
ThisisthestandardIPsecprocessingthatismoreor
lesscommonacrossdierentimplementations (and
even operating systems). Useof IPsec in
conjunc-tionwiththebridge,especiallyinthe\bumpinthe
wire"scenario,requiressomewhatdierent
process-ing. We shall describethese changes and
require-mentsinthenexttwosubsections.
3.2 Virtual LANs
Giventhewaythebridgingcodeoperates,in
partic-ularwithrespecttomemberinterfacesbeingadded
toandremovedfromthebridge,itwasasimple
ob-servation that we couldextend the role of theenc
interfacesothatitcouldbeusedbythebridge.
Ac-cordingly, we modied the enc interface such that
anincomingandanoutgoingSA canbeassociated
with it, throughthe standardifcong command 2
.
Currently, such SAs must bemanually congured,
viatheipsecadm utility.
2
works (LANs) may be bridged over a public
net-work. All that isnecessaryis that each LAN
con-tain an IPsec bridge connecting it to one ormore
otherLANs. Fromthepointof viewof thebridge,
theIPseclinkisidenticaltoanethernetnetwork,
al-lowingforcreationofarbitrarytopologies. Layer-2
andLayer-3ltering,spanningtreealgorithms,etc.
mayallbeused in theIPsec-bridgednetwork with
literallynochanges.
Themodicationsneededtotheencandbridge
in-terfacecodewereminimal. Forthebridge,theonly
changesnecessaryweretoallownon-ethernet
inter-facestobeattachedandinitializedproperly(for
ex-ample,itisnotnecessarytoswitchanencinterface
into promiscuousmode). Intheenc code, the
rou-tine that handles transmission was augmented to
passallenqueuedethernetframestoIPsecfor
pro-cessing and further transmission, after
encapsulat-ingtheminIPorIPv6. NotethatnoSPDlookupis
necessaryhere,sincetheoutputSAtouseisalready
known.
Tosupportmultiple bridgetopologiesonthesame
host,acongurablenumberofencinterfacesis
cre-ated. This number may be set at kernel compile
time. Byconvention,packets receivedon SAsthat
donothavean encinterfaceassociatedwiththem,
are made to appear as ifthey arrived onthe enc0
interface. Furthermore,theenc0interfaceisnot
al-lowedtohaveanySAsassociatedwithit,norcanit
beattachedtoabridge. Thus,packetsonSAsthat
have anenc interfaceassociated may be tracedor
lteredusing thatinterface. Forall otherSAs,the
enc0interfacemaybeused.
Implementation of the Ethernet-over-IP protocol
also proved straightforward, as the output side of
the protocol and the rst half its input processing
areidentical toIP-in-IPencapsulation. Atthe end
ofinputprocessing,ifitsinputinterfaceislinkedto
a bridge, the packet is passed to the bridge input
routine. IfaframeisreceivedoveranIPsecSA,its
input interfacewill bethe enc interface associated
withtheSA(seeFigures1and2).
Inall,lessthan300linesofadditionalcodeinIPsec
and the bridgewere necessaryto implemented the
virtualLANfunctionality.
Whenitcomesto performance,thehighestcostis,
asmight be expected, in the encryption. Figure 3
showsthecostofvariousalgorithms(and
combina-tication(thepacketsareunencrypted).
Note however that it is usually the case that
the wide-area network link over which the
vir-tual LAN is established is much slower than the
member LANs, and slower than the times shown
above. Thus, realistically, the performance is
lim-ited mainly by the interconnecting infrastructure.
The ltering capabilities of the bridge (blocking
multicast/broadcastandnon-IPpackets)canbe of
somevalue herein managing the volume of traÆc
sentovertheencryptedlinks.
Virtual LAN (vLAN) functionality is oered by a
numberof bridges,albeit itis used to mean
some-thingdierentfrom what wehavedescribed; more
specically,vLANsareusedtocompartmentalizea
physicalnetworkintoanumberof\isolated"LANs.
Themain goalis to decrease the traÆc \noise"as
seenbymachinesthatdonotneedtoprocessit(e.g.,
aprinterdoesnotneedtoreceiveNFSpackets;
like-wise, normal hosts on the subnet probably do not
need to see the AppleTalk packets the printserver
usestosubmitjobsto theprinter). Asideeect of
vLANemploymentisalimitedformofsecurityfrom
casualpacketsniÆng. SuchvLANsdo notprovide
thesamefeaturesourencrypting bridgeoers(and
viceversa).
3.3 Bump In The Wire
As mentioned in section 3, the bridge can also be
used as a transparent IPsec box, sitting in front
of a host ornetwork and IPsec-processing packets
traversingit. Thiscongurationiscalled\bumpin
the wire" (BITW) in the IPsec architecture. The
encrypting bridgeasdescribedin the previous
sec-tion can be used almost as-is when the protected
hostsornetworksareconguredtoonlytalktoone
remotehost(orsecuritygateway): anincomingand
outgoingSA paircanbeassociatedwithanenc
in-terfaceasbefore,andIPsecprocessingisdonealong
thesamelines. However,ratherthanencapsulating
ethernetframes inside IPpackets (andthen
IPsec-processing these), we extract the IP packets from
theethernet frames and doIP-in-IP encapsulation
instead. Theadministratorcanspecifywhichofthe
two types of encapsulation should be used simply
SoftwareAHMD5 67.87
SoftwareAHSHA1 47.79
SoftwareESPDES-MD5 19.56
SoftwareESPBlowsh-SHA1 23.61
SoftwareESP3DES-SHA1 9.07
HardwareESPDES-MD5 62.12
HardwareESP3DES-SHA1 63.12
Figure 3: Throughput ofa TCPsession overIPsec betweentwoK6-3/550 boxesdirectly connected with
100Mbit/sethernet. Forthehardwarenumbers,weusedacard withtheHi/Fn7751chip.
The SAs associated with the enc interface (which
must be manually congured) can use the IP
ad-dress of the bridge, or the IP address of the
pro-tectedhost. Intheformercase,thebridgeexhibits
theexactsamecharacteristicsasanencrypting
gate-way(packetssenttotheremotehostorgatewaylist
the bridge's IPaddress as the source); in contrast
toagatewayhowever,nocongurationchangesare
necessary in the network or the protected host(s)
whenplacingthebridge. SinceSA congurationis
manual,therearenoissueswithauthentication
dur-ingkeyestablishment(asdescribedinsection3).
Whenthe SAs usetheIP addressof theprotected
host, the bridge is totally transparentto both the
protectedhostandthedestinationhostorgateway.
There are two issues that need to be addressedin
thiscongurationhowever:
TheIPsecstandardspeciesthatIPfragments
should not be IPsec processed in transport
mode. That is, fragmentation must occur
af-terIPsecprocessinghastakenplace,ortunnel
mode (IP-in-IP encapsulation) must be used.
Thus, the bridge must either use only tunnel
mode IPsec, or reassemble all fragments
re-ceived from the protected host, IPsec-process
the re-constructed packet, then fragment the
resulting packet. For performance and
sim-plicity reasons, we decided to use the former
approach. Thedisadvantageis that all
IPsec-processedpackets are20 byteslarger(the size
oftheexternalIPheader).
Since the remote host is not aware of the
en-crypting bridge'sexistence, IPsec packets will
beaddressedtotheprotectedhostornetwork.
Thus,wehavetomodifythebridgetorecognize
these addresses and process those IPsec
pack-The bridge only has to watch for IPsec
pack-ets (transport protocol ESP or AH), and use
the information in the packet to perform an
SA lookup. If an SA is found, the packet is
processed. Otherwise,itmaybedroppedor
al-lowed through depending on the ltering
con-guration.
AhybridSA congurationmaybeused(wherethe
bridgeusesitsaddressinonedirection,andthe
pro-tectedhost'saddressintheother). Such a
congu-rationdoesnotseemtooeranysubstantialbenet
however(andmayinfactresultinconfusingthe
ad-ministrator).
3.4 Transparent Policy Enforcement
Whilethemechanismdescribedintheprevious
sub-sectionisusefulinitsownright,itsusefulness
dra-maticallyexpandswhenthebridgeismodiedsuch
thatitcanautomaticallyestablishSAsonbehalfof
theprotectedhosts.
Our IPsec implementation already supports
dy-namic SA acquisition by notifying a key
manage-ment daemon like isakmpd [4] using the PF KEY
interface. SAacquisitionoccursinthefollowingtwo
cases:
An application requests some security service
on a socket, by using the setsockopt() system
call,andnoSAsappropriateforthetraÆc
pat-ternorsecuritylevelexist.
The kernel decides that a packet needs to be
IPsec-processed,butnoappropriateSAsexist.
to dynamically establish SAs: when an IP packet
(rather,anethernetframecontaininganIPpacket)
reaches the bridge and is about to be
\transmit-ted"overanencinterface,anSPDlookupismade.
IfanSA appropriateforthispacketalreadyexists,
it is used. Otherwise, the packet is dropped and
a notication is sent to the keymanagement
dae-mon to establish such an SA. The granularity of
theSAmaybeconguredbytheadministrator(the
sameSAmaybeusedforalltraÆcbetweenthe
pro-tectedandtheremotehost,orjustthespecicTCP
connectionmaybeprotected). Futurepacketswith
thesame characteristicsas theoriginal packet will
makeuseofthenewly-establishedSA.Fortunately,
nochangestotheSPDarenecessary.
Thismechanismmaybeusedtoperformautomatic
re-keyingforthevirtualLANorthesimple\bump
inthewire"congurationsdescribedintheprevious
twosubsections.
However, left to its own devices, key management
will establish an SA using the IP address of the
bridge (and thus end up beingfunctionally
equiv-alenttoanencryptinggateway). Toreallyhidethe
bridgefrom the remotehost,thesource addressof
the protected host must be used. Thus the key
management daemon, isakmpd, has to operate in
the \bridge mode," wherein it asks the kernel to
use anon-local IP address. This requires a minor
change in the bind()system callcode, to allowfor
socket binding to non-local addresses. To capture
theresponses,allUDPtraÆctoport500(theport
usedbytheIKE protocol)isdivertedtothebridge
isakmpd. This isalso necessarywhenremotehosts
attempt to initiate an IKE exchange with a
pro-tected host. In both cases, isakmpd must be
in-formed of and use the \local" address associated
with the incoming packet. isakmpd also needs the
\local"address soas to select theappropriate
au-thentication information (e.g., secret DSA [15] or
RSA [12] key when doing X.509 or DNSSEC
au-thentication). Thechangesto this eect are fairly
minimal.
Incoming IPsec packets areprocessedas described
intheprevioussubsection. Otherincomingpackets
maycauseanSAacquisition,dependingonthe
secu-ritypolicysetbytheadministrator. Again,isakmpd
needsto be informedof what IPaddressto useas
thesourceaddressduringtheexchange.
Thecombinationofpacketlteringthroughipfand
network security policy for the protected host(s).
One particularly interesting conguration involves
the bridge establishing SAs for unencrypted-only
traÆc; if end-hosts use IPsec or SSL for
end-to-endpacketsecurity,thebridgesimplyforwardsthe
packets. In another conguration, the bridge
per-mitsallpacketsthrough,but attempts toestablish
SAs forsuchcommunicationsand usesthem ifthe
remote hosts cando IPsec(also known as
\oppor-tunisticencryption").
4 Implementation Status and Future
Work
Currently, the bridge lacks support for the
span-ningtreeprotocolwhichispartoftheIEEE802.1D
standard[16], so caremustbetakento ensurethat
loopsare notcreatedin the network. The Layer-2
lter rule system should be extended to provide a
generalmechanismforlteringspecicethernet
pro-tocols. Wealsointendtoextendthebridgetoallow
forothertypesofLANbridging(FDDI,PPP,etc.).
WithregardstodynamicSAestablishment,all
traf-cthattraversesthebridgeconguredin the
man-nerdescribedin section3.4 causesSAacquisitions.
Thisisbothundesirableandcanhavesevere
perfor-manceimplications. Amechanismforthe
adminis-tratorto specify which packet owsshould require
IPsecprotection(andthuscauseanSAacquisition)
isnecessary. Wearecurrentlyworkingonthisissue.
Moreworkneedstobedonewithregardstothe
per-formanceimplicationsoffrequentIKEnegotiations,
asmightbethecasewhenthebridgeisprotectinga
largenetwork. Hardening againstdenial of service
attacks(byexploitingtoo-aggressiveSAacquisition
rules)isalsohigh inourto-dolist.
The ltering bridge can also provide a transition
stepfora\distributedrewall"-protectednetwork,
asdescribedin [1]. Itmayalsobeusedin
conjunc-tionwithadistributedrewalltoprovideprotection
againstlow-levelnetwork attacks(thosethat a
dis-tributedrewallisnotwell-suitedtocounter),orto
protectlegacysystems that cannot bemodiedto
supporttherequiredfunctionality. Verylow-priced
systems (motherboard, processor, small disk, two
iouscommercialproductsthathavebeguntomake
theirappearancein themarketrecently.
5 Conclusions
WehavegivenanoverviewoftheOpenBSDbridge
implementation,withourextensionsforLayer-2and
Layer-3 ltering (at the ethernet and IP layer,
re-spectively). Forthelatter,weusedtheexisting
ker-nel packet lter mechanism, ipf. We further
pre-sented our integration of bridging with IPsec to
provide\virtualLAN"functionality,
\bump-in-the-wire"support,andatransparentsecuritypolicy
en-forcement box. This latter conguration is shown
tooersignicantexibilitytonetwork
administra-tors,asitcanbeusedinvariousmodesofoperation
toensuretraÆcaswellashostandnetwork
protec-tion. Finally,wediscussedthecurrent
implementa-tionstatusandourplansforfuturework.
6 Acknowledgments
The bridge was originally developed as an
under-graduate independent study at the University of
NorthCarolina at Greensboro byJason L. Wright
with Dr. Suzanne Lea as an advisor. The code
wascontributedto theOpenBSD projectand
inte-grated into thesource tree prior to the2.5 release
(May1999).
TheauthorswouldalsoliketothankTheodeRaadt
andJonathan Smithfortheirsuggestionsand
sup-portduringthecourseofthiswork.TheodeRaadt
suggestedmanyoftheoriginalconceptsbehindthe
lteringbridgeandthevirtualLAN.Thisworkwas
partly sponsored by DARPA under grant
F39502-99-1-0512-MODP0001.
7 Availability
All thesoftwaredescribed inthe paperisavailable
throughtheOpenBSDwebpageat:
http://www.openbsd.org/
OpenBSDisbasedinCalgary,Canada. All
individ-ualsdoingcryptography-relatedworkdosooutside
countries thathavelimitinglaws.
References
[1] S.M.Bellovin. DistributedFirewalls. ;login:
mag-azine,special issueonsecurity,November1999.
[2] Consultation Committee. X.509: The Directory
Authentication Framework. International
Tele-phoneand Telegraph,International
Telecommuni-cationsUnion,Geneva,1989.
[3] D.EastlakeandC.Kaufman.DynamicName
Ser-vice and Security. Internet RFC 2065, January
1997.
[4] NiklasHallqvistandAngelosD.Keromytis.
Imple-mentingInternetKeyExchange(IKE).In
Proceed-ingsoftheAnnualUSENIXTechnicalConference,
June2000.
[5] D. Harkins and D. Carrel. The internet key
ex-change (IKE). Request for Comments(Proposed
Standard)2409, Internet Engineering TaskForce,
November1998.
[6] P. Karn and W. Simpson. Photuris: Session-key
managementprotocol.RequestforComments
(Ex-perimental)2522,InternetEngineeringTaskForce,
March1999.
[7] S.KentandR.Atkinson.IPauthenticationheader.
RequestforComments(ProposedStandard)2402,
InternetEngineeringTaskForce,November1998.
[8] S.KentandR.Atkinson.IPencapsulatingsecurity
payload(ESP). Requestfor Comments(Proposed
Standard)2406, Internet Engineering TaskForce,
November1998.
[9] S.KentandR.Atkinson. Securityarchitecturefor
theinternetprotocol.RequestforComments
(Pro-posed Standard) 2401, Internet Engineering Task
Force,November1998.
[10] A. D. Keromytis, J. Ioannidis, and J. M. Smith.
ImplementingIPsec.InProceedingsofGlobal
Inter-net(GlobeCom)'97,pages1948{1952,November
1997.
[11] KirkMcKusick,et.al. TheDesignand
Implemen-tation of the 4.4BSD Operation System. Addison
Wesley,1996.
lter: Anewarchitectureforuser-levelpacket
cap-ture. InProceedings ofUSENIX Winter Technical
Conference, pages259{269, SanDiego,California,
January1993.Usenix.
[14] D.McDonald,C.Metz,andB.Phan.PF KEYKey
Management API, Version 2. Request for
Com-ments (Informational) 2367, Internet Engineering
TaskForce,July1998.
[15] DigitalSignatureStandard,May1994.
[16] Internetworking Task Group of IEEE 802.1.
In-formationtechnology{telecommunicationand
in-formation exchange between systems { local and
metropolitan area networks { common
specica-tions{part3: Mediaaccesscontrol(mac)bridges.
Technical Report ISO/IEC Final DIS 15802-3,
IEEE P802.1D/D17, LANMAN Standards
