"A Full Bandwidth ATM Firewall"

OlivierPaul ??

,Maryline Laurent,andSylvainGombault

ENSTdeBretagne,2ruedelachataigneraie,35510Cesson-Sevigne,France.

fpaul|mlaurent|sylvaing@renn es.e nst-b reta gne. fr

Abstract. Inthispaperwedescribeanarchitectureprovidinganhigh

speedaccesscontrolserviceforATMnetworks.Thisarchitectureisbased

ontwo main components.The rst one is a signalling analyserwhich

takesthesignalling information asaninput andproducesdynamically

thecongurationforoursecondmodule.ThissecondmodulecalledIFT

(Internet Fast Translator) is used to analyse the information located

in the ATM cells and currentlyoperates at 622 Mb/s. The complete

architectureprovidesthe access control at theATM,IP and transport

levelswithoutpacketreassembling.

1 Introduction

In the recent past, much attention has been paid developing security services

forATM networks.Thisresultedinthecreationofmanyworkinggroupswithin

(andoutside)thestandardisationbodies.OneofthemistheATMForum

secu-rityWorkingGroupcreatedin1995,whichreleaseditsversion1.0specications

inFebruary1999.Condentiality,authentication,integrityandsomekindof

ac-cesscontrolhavebeenconsidered.Accesscontrolasdened bytheISOin[1]is

asecurityserviceusedtoprotectresourcesagainstunauthoriseduse.TheATM

technologyhasbeenspeciedtotransportvariouskindsof owsandallowsusers

tospecifytheQoS(QualityofService)applyingtothese ows.Communications

areconnectionorientedandasignallingprotocolis usedto setup,control and

releaseconnections.Inthisarticleweshowthattheclassicalapproachsupplying

the access control service (commonly called rewall)is unable to preservethe

QoS.Wethen describeanewaccesscontrolarchitectureforATMand

IP-over-ATM networks.Thisarchitecture calledCARAT doesnotalter thenegotiated

QoS. The next section analyses current solutionsproviding the access control

serviceintheATMandIPoverATMnetworks.Section3describestheCARAT

architecture.Thisoneisbasedontwomain components.Therstoneisa

sig-nallinganalyserwhichtakesthesignallinginformationasaninputandproduce

dynamicallythecongurationofoursecondmodule.Thissecondmodulecalled

IFT(InternetFastTranslator)isusedtoanalysetheinformationlocatedinthe

ATM cellsat 622Mb/s.Asaconclusionweperformacomparison betweenour

solution and other proposed approaches and we show that CARAT is agood

alternativetocurrentsolutions.

Several solutionshavebeen proposed in orderto provide somekind of

access-control in ATM and IP overATM networks. This section is divided into four

parts.IntherstpartweconsidertheadaptationoftheInternet"classical"

re-wallarchitecturetoATMnetworks.Inthesecondpartwedescribethesolution

proposed by the ATM Forum. Inthe third part we describe various solutions

proposedtoimprovethe"classical"rewallsolution.Finally,partfourcompares

existingsolutionsandhighlightsthemain problems.

2.1 Classical Solution

The rst solution[9] is to usea classicalrewalllocated between the internal

andpublicnetworksinordertoprovideaccess-controlatthepacket,circuitand

application levels. As such the ATM network is considered as a level 2 layer

oeringpointtopointconnections.Asaresultaccess-controlat theATM level

isnotpossibleandendtoendQoSisnolongerguaranteed.AttheIPandcircuit

levels,IPpacketsarereassembledfromtheATMcells.Access-controlissupplied

usingtheinformationembedded intheTCP,UDPandIPheaders. Packetsare

lteredbycomparingtheeldsintheheaderssuchasthesourceanddestination

addresses,thesourceanddestinationports,thedirectionandtheTCP agswith

a pattern of prohibited and allowed packets. Prohibited packets are destroyed

whereas allowed packets are forwarded from one interface to the other. When

the sameQoS is negotiated on bothsides of the rewall, theend to end QoS

maybemodiedinthefollowingways:

{ Reassembly, routing, ltering and deassembly operations increasethe Cell

TransitDelay.

{ InternaloperationsdoneoverIPpacketsmayincreasetheCellLossRatio.

{ Thetime spent to reassemble and disassemble the packets is proportional

to thepacket sizes, which arevariable. As aresult, theCell Transit Delay

VariationmaybedierentfromtheCDVTvaluenegotiatedoneachsideof

therewall.

{ Routingandlteringactionsoperateatthesoftwarelevel.Thustheloadof

thesystemmaycausevariationsintheSustainableandMinimumCellRate.

Application procedures are then ltered at the application level by proxy

applications in accordancewiththe securitypolicy.Like withtheIPorcircuit

levellters,theQoSisaected,butmuchmorestrongly,sincethetraÆchasto

reachtheapplication level.Moreoversincethelteringoperationsareprovided

in amultitasking environment,desynchronisationbetweenthe owscanoccur.

Thiskindofsolutionisreportedtohaveperformanceproblems inahigh speed

networkenvironment([3],[5]).Thelatesttests([6])showthatthisaccesscontrol

solutionisunsuccessfulat theOC-3 (155Mb/s) speed. Finally, [17]has shown

that load balancing techniques between several rewalls could partially solve

Theaccess-controlserviceasdenedin theATM Forum securityspecications

([10]) is based on the access- control service provided in the A and B orange

bookclassiedsystems.Inthisapproachonesensitivitylevelperobjectandone

authorisation level persubject are dened. These levelsinclude a hierarchical

level (e.g. public, secret, top secret, etc.) and a set of domains modelling the

domainsassociatedwiththeinformation(e.g.management,research,education,

etc.).Asubjectmayaccessanobjectifthelevelofthesubjectisgreaterthanthe

leveloftheobjectandoneofthedomains associatedwiththesubjectincludes

oneofthedomainsassociatedwiththeobject.IntheATMForumspecications,

the sensitivity and authorisation levels are coded according to the NIST [4]

specicationasalabel,whichisassociatedwiththedatabeingtransmitted.This

labelmaybesentembeddedintothesignalling,orasuserdatapriortoanyuser

dataexchanges.Theaccess-controlisoperatedbythenetworkequipmentwhich

veries that the sensitivity level of the data complies with the authorisation

levelassigned to the links and interfacesoverwhich thedata are transmitted.

The main advantage of this solution is its scalability since the access control

decisionis made at theconnectionset-up and doesnotinterfere with theuser

data.Howeveritsuersfromthefollowingdrawbacks:

{ Thenetworkequipmentisassumedtomanagesensitivityandauthorisation

levels.Thisisnotprovidedincurrentnetworkequipment.

{ Aconnectionshould beset upforeach sensitivitylevel.

{ Theaccess-control serviceasconsidered in traditionalrewalls(i.e.

access-controltohosts,services)isvoluntarilyleftoutsidethescopeofthe

speci-cation.

2.3 Specic solutions

Theabovelimitationshavebeenidentiedandmanyproposalshavebeenmade

in order to supply the "traditional" access-control service in ATM networks.

Thesesolutionsmaybeclassiedintotwoclasses:industrialandacademic

solu-tions.

Industrial solutions

Therst industrial solution(Cisco [14],Celotek,GTE)uses aclassical ATM

switch that is modied to lterATM connectionset up requestsbased onthe

source and destination addresses. Theproblem with this approach is that the

access-controlisnotpowerfulsincetheparametersareverylimited.Thesecond

one(Storagetek[13])isalso basedonanATM switch.Howeverthisswitchhas

beenmodied tosupply access-control at theIPlevel.Insteadof reassembling

cellsfor packet headers examination likein traditional rewalls, thisapproach

CAM(ContentAddressableMemory)designedto speeduptheresearchin the

access-controlpolicy.Thisapproachistherstonetakingintoaccountthe

lim-itations introduced by theclassical rewall approach. Howeversome problems

havenotyetbeensolved:

{ Access-controlislimitedto thenetworkandtransportlevels.ATMand

ap-plicationlevelsarenotconsidered.

{ IP packets including options are not ltered since options may shift the

UDP/TCP information in the second cell. This causes a serious security

aw.

{ Thedevice isnoteasyto manageespeciallywhen dynamicconnectionsare

required,sinceconnectionltershavetobecongured manually.

{ Performances of the device are not very scalable. An OC-12 (622 Mb/s)

versionofthisproductwasannouncedin1996buthasnotbeenyetexhibited.

Academic solutions

Both academic solutions being proposed are based on the above Storagetek

architecture, but they introduce some improvements to cope with Storagetek

problems.

Therstapproach[2]usesanFPGAspecialisedcircuitassociatedwitha

mod-ied switch architecture. At the ATM level, the access control at connection

establishmenttime isimprovedby providing lteringcapabilities basedonthe

source and destination addresses. This approach also allows ATM level PNNI

(PrivateNetworktoNetworkInterface)routinginformationtobeltered.Atthe

IPandcircuitlevelstheaccess-controlserviceissimilartotheoneprovidedby

theStoragetekproduct.Thissolutionisinterestingsinceitisthemostcomplete

solutionbeingcurrentlyimplemented.Howeveritsuersfrommanylimitations:

{ Special IP packets (e.g. packets withoptional elds in the header) arenot

processed.

{ Onlyasmall partof theinformation suppliedbythe signalling(i.e.source

anddestinationaddresses)isused.

{ Access-controlattheapplicationlevelisnotconsidered.

{ Onlyasmallpartof theproposalhasbeenimplemented.

The second approach [11] is the most complete architecture being currently

proposed.This solution provides many improvements in comparison with the

Storagetek architecture. The most interesting idea is the classication of the

traÆc. ThetraÆc isclassiedintofour classesdepending ontheATM

connec-tion QoS descriptors and on the processing allowed to be done over it. Class

AprovidesabasicATM access-control.ATMconnectionsarelteredaccording

ad-is blocked.Class Cis associatedwith packetltering. IPandtransport packet

headersarereassembledfromtheATM cellsandanalysed.Duringthisanalysis

thelast cellbelonging tothe packet called LCH (Last CellHostage)is keptin

memorybytheswitch.Theanalysisshouldbeatleastfasterthanthetimespent

bythewholepacketcrossingtheswitch.Whenthepacketisallowed,theLCHis

released,butwhenthepacketisprohibitedtheLCHismodiedsothataCRC

erroroccursandthepacketisrejected.ForclassD,theaccesscontrolprocessing

issimilarto thatoftherewallproxy.

Table 1.AccessControlClasses

Level/ApplicationWithQoS RequirementsWithoutQoSRequirements

ATM ClassA ClassA

TCP/IP ClassB ClassC

Application NoAccessControl ClassD

This classicationexpects the switch to separate traÆc with QoS

require-mentsfrom traÆc withoutQoSrequirements.As such thetraÆc withQoS

re-quirementsis allowed to crossthe switch withoutbeingdelayed.Table1gives

thelteringoperationsdepending onthelevelimplementingtheaccess control

andthetraÆcQoSrequirements.

This approach is very interesting since it introduces many improvements

(traÆcclassication,LCH)overalltheotherproposals.Howeversomeproblems

remain:

{ Few parametersare used to supplythe access control serviceat the ATM

level.

{ Access control is not provided at the application level for applications

re-quiringQoS.

{ TraÆcmonitoringonlyappliestoconnectionorientedcommunications,and

UDPpacketscannotbelteredusingthistechnique.

{ TheLCHtechniqueisuselessagainstinformationleakagesincean internal

usercandecidetobypasstheintegritychecksontwoendsystemson both

sidesoftherewall.

{ Thisarchitectureiscomplex.Noimplementationhasbeenexhibited.

2.4 Conclusion

As a conclusion, table 2 compares all the competing approaches designed to

provide access control on both ATM and IP over ATM networks. The ATM

forum proposal has not been included in this comparison since this solution

requiresdeepchangesin theexistingequipment.

Property/ApproachClassical Filtering ATM McHenryXu CARAT

Firewall [9]Switch[14]Firewall[13]&al.[2] &al.[11]

ATMlevelA.C. No Poor No Poor Poor Good

TCP/IP A.C. Good No Average Average Average Average

ApplicationA.C. Good No No No Good No

ImpactontheQoS Large Low Low Low Low Low

Manageability Good Good Poor Poor Good Good

Implementation Yes Yes Yes Partly No Yes

Bandwidth(Mb/s) 150 622 155 155 / 622

to lter ATM connections on addresses. One of the goals of CARAT is solve

thisproblembyusinganimprovedsignallinganalyserwhichallowsthesecurity

oÆcertocontrolalmostalltheparametersthatcanbeusedtodescribeanATM

connection.

Anotherpointisthebalance betweenperformance, impactontheQoSand

qualityoftheaccesscontrol.Mostofthecurrentsolutionseitherprovideagood

security levelwhile oering poor performance and large QoS modications or

providealowersecuritylevelwhileoeringgoodperformanceandsmallimpact

ontheQoS.ThegoalofCARATinthis eldistoreachasecuritylevelsimilar

to theoneprovided byatraditionalstateless packet lterwhileoeringbetter

performance than the existing cell basedproposals. Similarlyto [11],CARAT

can be easily extended to provide application level access control for

applica-tions withoutQoS requirements. As aconsequence the securitylevelprovided

by CARAT is at leastasgood astheXu and al. proposal which hasnot been

implemented.

The last point is that current cell based proposals rely on the caching of

accesscontroldecisionsinordertospeed-upthecellclassicationprocess.This

cacheis lledthroughaslowcellclassicationprocess that analysescells that

can notbeclassiedthroughtheinformationlocatedin thecache.However,as

demonstrated in [18],these kindof architecture is subject to denial of service

attacks because hackers can produce a traÆc that will always generate cache

misses thus forcing the cell classication process to work at the speed of the

slow softwareclassication scheme. These attackscanreduce dramaticallythe

performanceofcachebasedproposals.Ontheotherhand,CARATsucceedsto

store the complete access control policy ([15]) by using a policy compression

techniqueandapatentedstoragemethod. ConsequentlyCARATisnotsubject

to similarDoS attacks.

3 Proposed solution

As depicted in gure1, CARAT is basedon two main parts.The rst partis

ATM

IFT

IFT

Signaling

Analyser

Manager

ATM

IFT

Driver

ATM Switch

Internal Network

External Network

Controller

Sun Workstation

PC Station

Daemon

Fig.1.Controllerprototypearchitecture

theATM cells.Thissecondpartisableto retrievetheATM,IPand transport

levelinformationin ordertodecidewhetheracommunicationhastobeallowed

or denied. The congurationof the whole controller is made througha single

language.

3.1 An AccessControl Policy DenitionLanguage

InordertoexpresstheaccesscontrolpolicywedeneanAccessControlPolicy

Description Language(ACPDL).This language is basedon draft proposal for

apolicy descriptionlanguage[7] which hadbeendened in 1998by thepolicy

workinggroupattheIETF.Inthislanguageanaccesscontrolpolicyisdescribed

byasetofrules.Eachruleconsistsofasetofconditionsandoneactionwhichhas

to beexecutedwhen theconditionsaremet. ThefollowingBNF(Backus-Naur

Formalism)expressiondescribestherulesyntax.Rule::=IF<Conditions>THEN

<Action>Alltheconditionshavethesamegenericstructure(BNFnotation):

Condition ::= <ACCESS CONTROL PARAMETER> <RELATIONAL OPERATOR>

<VALUE>

Dependingonthelevelin theprotocolstack,variousaccesscontrol

parame-tersmaybeused:

{ AttheATMlevelusefulaccesscontrolparametershavebeendescribedin[8],

whichincludethetraÆctype,connectionidentiers,addressinginformation,

QoSdescriptorsandserviceidentiers.

{ Atthetransportlevelmostoftheincludedparametersarecommonlyusedto

Action ::= <ACTION> <ACTION LEVEL>

The actioncan beto permit orto deny thecommunication. The level

de-scribesthelayer(i.e.ATM,Transport)wheretheactionhasto beexecuted.

IF ( SRC ADDRESS = 47.007300000000000000002402.08002074E457.00 ) AND

( DST ADDRESS = 47.007300000000000000002404.0800200D6AD3.00 ) AND

(BHLI TYPE = 04 ) AND ( BHLI ID = 00A03E00000002 ) THEN DENY.

Fig.2.AccessControlRuleExample

Figure2providesanexampleofhowaruleprohibitingconnectionsbetween

twoATM devicesfortheVideoOnDemandservicecanbeexpressedusingthe

ACPDL.InthisexamplebothdevicesareidentiedbytheirATMaddressesand

thevideoserviceisidentiedbytheBroadbandHigherLayerIdentier(BHLI).

3.2 The Manager

ThepolicydenedbythesecurityoÆcerusingthislanguageisusedtocongure

thetwopartsofouraccesscontroller.Howeverthepolicycannotbeuseddirectly

byouraccesscontrol tools.Asaresultthemanagerhastotranslatetheaccess

controlpolicyinrelevantaccesscontrolcongurationsforbothourcomponents.

Thewholetranslationprocessisdescribedingure3.

Cell−level Information

Dynamic TCP/IP and

Dynamic Cell−level

Access Control Policy

TCP/IP Generic

Static Cell−level

Access Control Policy

Signaling Access

Control Policy

Signaling

Information

Access Control Policy

Access Control Policy

Access Control Policy

Cell−level

Fig.3.AccessControlPolicyGenerationProcess

communicationsthathavetobecontrolled.Eachcommunicationisdescribed

byasetofInformation Elements(IEs)and anaction(DENYorALLOW).

Thiscongurationissenttothesignallinganalyser.

{ AttheTCP/IPlevel,thecongurationincludesadescriptionofpacketsthat

haveto becontrolled. This partof the policy is genericwhich means that

thiscongurationisnotdedicatedtoaspecic ATMconnection.

{ At the celllevel, the conguration includes adescription of the cells that

havetobecontrolled.Thesecellsaredividedintoaset ofelds.Theset of

valuesthateacheldcantakeisdescribedthroughatree.Thisconguration

isdirectlysenttotheIFTmodules.

Thesecond part ofthe congurationprocess occurs when aconnection

re-questisreceivedbythesignallinganalyser.Oncetheaccesscontrolprocesshas

beencompleted,thesignallinganalysersendstothemanagerthepiecesof

infor-mationneededtocompletethedynamiccongurationoftheIFTs.Thisdynamic

conguration process is important since it allowsthe size of theconguration

storedintheIFTstobereducedincomparisontoastaticconguration.Thesize

of thecongurationis animportantissue becausethe delay introduced bythe

IFTduring theaccesscontrol processdependsonit.Theinformationprovided

bythesignallinganalyserincludes:

{ TheVciandVpiconnectionidentiers.

{ ThesourceanddestinationATM addresses.

{ Theservicedescriptor(ClassicalIPoverATM(CLIP),NativeATM

Applica-tion).WhenanadditionallayerisusedabovetheATMmodel,thesignalling

analyseralsoprovidestheencapsulation(withorwithoutSNAP/LLC

head-ers).

{ Thedirection ofthecommunication.

InaCLIP environment,themanagerusestheATM sourceand destination

addressestondthecorrespondingIPaddresses.Thistranslationisdonedirectly

by using a local le describing the matching betweenATM and IP addresses.

HoweverthisprocesscouldbeimprovedbytakingadvantagefromanATM

Ad-dressResolutionProtocolServers.ThemanagerthenusestheTCP/IPgeneric

accesscontrolpolicytondamatchbetweentheIPaddressesandtheTCP/IP

levelaccess control rules. The subset of matching rulesis used along with the

otherpiecesofinformation(addresses,encapsulation,connectionidentiers,

di-rection)tocompletethecongurationoftheIFTcards.Theyarekeptduringthe

connectionlife.Attheconnectionrelease,themanagerreceivesamessagefrom

thesignallinganalyserto recongureIFTscards andclean theirconguration.

Themanagerthendestroystheinformationassociatedtotheconnection.

3.3 The SignallingAnalyser

redi-todecomposethesemessagesaccordingto theUNI3.1specication[12] andto

forwardordropthemaccordingtotheaccesscontrolpolicydescriptionprovided

bythemanager.

ATM Switch

SUN Workstation

0

1

6

1

3

2

Internal

Network

External

Network

Fig.4.ATMSwitchConguration

Inorder to redirect thesignalling, the ATM switch hasto be recongured

to redirect signalling messages to the SUN workstation as described in gure

4. This conguration can be achieved by disabling the signalling protocol on

interfaces1,2,3and6.AVirtualPathhasthentobedenedbetweeneachpair

ofinterfacesforeachpossiblesignallingvirtualchannel.These virtualchannels

areidentiedbythevciconnectionidentier5.

SUN Workstation

Kernel Space

Filter

Signaling Module Message

Parsing

Signaling Module Message

Construction

User Space

Q93B Module

SSCOP Module

SSCOP Module

ATM Interface 0

ATM Interface 1

Fig.5.SignallingFilteringProcess

ex-scribedbygure5,allsignallingmessagesareusuallymultiplexedbytheQ93B

module whose goal is to establish, manage and release ATM connections. In

order to preventsignallingmessagesfrom beingrejected bytheQ93B module,

this module has to be modied to forward all the signalling messages to the

lterapplicationlocatedin theuserspacewithoutfurtheranalysis.Inorder to

dierentiatethelteringprocessforincomingandoutgoingmessages,signalling

messagesareassociatedwiththeoriginatingATMinterface.Thisinformationis

providedtothesignallinglterbytheQ93Bmodule.

Whensignallingmessagesarereceivedbythesignallinganalyser,these

mes-sagesareparsedbythemessageparsingmoduleintoInformationElements(IEs)

accordingtotheUNI3.1specication.IEsarethenparsedintobasicconnection

descriptorssuchasaddresses,connectionidentiers,callreference,QoS

descrip-tors andserviceidentiers. Theanalyserthen checkswhether themessagecan

beassociatedwithanexisting connectionthroughthetypeofthemessageand

thecallreferenceinformation.Iftheconnectionisnew,aconnectiondescription

structure is constructed. When the connection already exists, the structure is

updatedaccordingtothenewconnectiondescriptionparameters.Theresulting

set ofparametersisassociatedwith theconnectionstate,theoriginating

inter-face and identied by aconnectionidentier. Thewhole structureis then sent

to thelterforanalysis.

Whenthelterreceivesanewconnectiondescriptor,itcomparesthe

connec-tionparameterswiththeset ofcommunicationsdescribedbytheaccesscontrol

policy. If a match is found, the lter applies the action described by the

ac-cess control policy. When the action is to deny the communication, the lter

destroysthecorrespondingconnectiondescriptionstructure.Otherwisethe

con-nection identier is sentto themessage construction module. ForCONNECT

signallingmessages,asubsetoftheconnectionparametersissenttothemanager

as described in the previous section so that thedynamic partof the cell-level

accesscontrol policy canbegenerated:

{ VciandVpiareretrievedfromtheConnectionIdentierIE.

{ Sourceanddestination addressesareretrievedfromtheCalledandCalling

PartyIdentierIEs.

{ Theservicedescriptorscanberetrievedfrom theBroadbandHigher Layer

Identier(BHLI)andBroadbandLowerLayerIdentier(BLLI) IEs.

{ Thedirectionisprovidedbytheinterfacenameassociatedwiththe

connec-tionidentier.ForRELEASECOMPLETEmessages,theconnection

iden-tierissenttothemanager.Thecommunicationsbetweenthelterandthe

managerare realised by using ashared memorysegment which allowsthe

managertosendtheaccesscontrolpolicytothesignallinganalyserandthe

lterto sendtheresultsfromthelteringprocesstothemanager.

Whenthemessageconstructionmodulereceivesaconnectionidentiersfrom

tion state associated to the connection identier indicates that a RELEASE

COMPLETEmessagehasbeensenttoreleasetheconnection,theconstruction

module freestheresourcesassociatedwiththecorrespondingconnection.

Another functionality provided by the message composition module is the

abilitytomodifytheATM sourceaddresswhenthecommunicationcomesfrom

theinternal networkto hide thestructureof thenetwork.This functionality is

providedbychangingthesourceaddressintotheATMaddressoftheworkstation

externalATMinterface.

Thedelayintroducedbythewholesignallinganalysisprocesshasfewimpact

onthecommunicationsincethestandardisedsignallingtimeoutvalueshavebeen

greatlyoversized(forexamplea14secondsdelayisallowedbetweenSETUPand

CONNECTmessages).

3.4 IFT cards

The Internet Fast Translator(IFT) card ([15], [16]) isa productdesigned and

manufacturedbytheresearchbranchofourindustrialpartner.Thesecardhave

beenoriginallydesignedto implementanhigh speedIPpacketroutingengine.

Howeverthiscardintegratesseveralinterestingfeaturesthatcanbeusedbyour

ATM rewall:

{ ItallowstherstcelloftheAAL5frametobeanalysedandtheconnection

identierstobemodiedaccordingtotheanalysis.

{ Thecurrentprototypeworksat622Mb/sthankstoapatentedcellanalysis

scheme.

{ Thedelay introducedby the cellanalysis process canbebounded and

de-pendsonthecellanalysis conguration.

{ Itcanbecongureddynamicallyduringthecellanalysiswithout

interrupt-ingongoingoperations.

{ ItcanbeintegratedintoanotheshelfpersonalcomputerusingtheSolaris

x86operatingsystem.

Table 3 describes the information available for analysis in the rst ATM

cell with the CLIP and CLIP (without LLC-SNAP encapsulation) protocols.

TheUDandTDeldsindicatethebeginningofUDPandTCPdatasegments.

However optional elds such as IP options have not been indicated and may

shift TCP or UDP related information in a second ATM cell. Our policy for

thesekindofcellsiscurrentlyto dropallthepacketsincludingIPoptions.One

mayconsiderthispolicytobeaseverelimitation,howeversimilaraccesscontrol

policiesareusually implementedontraditionalrewallssincetheseoptionsare

used most of the time by hackersto generate DoS attacks or bypassexisting

routingmechanisms.

Therstpartofthecell-levelaccesscontrolprocess istodirectallthe

Byte 1 2 3 4 5 6 7 8 9 10 11 12

CLIP1 ATMHeader AA AA 03 00 00 00 08

CLIP2 ATMHeader 45 Length

Byte 13 14 15 16 17 18 19 20 21 22 23 24

CLIP1 XX 45 Length P

CLIP2 P SrcIPAddr DstIP

Byte 25 26 27 28 29 30 31 32 33 34 35 36

CLIP1 SrcIPAddr Dst IPAddr SrcPort Dst

CLIP2 Addr SrcPort DstPort UD

Byte 37 38 39 40 41 42 43 44 45 46 47 48 CLIP1 Port UD D CLIP2 D TD Byte 49 50 51 52 53 CLIP1 CLIP2

signallinganalysisprocess.Asaresulttheswitchhastobeconguredtocreate

avirtualchannelforeachvalueofvcidierentfrom5and31betweeneachpair

ofinterfaces(1,4and5,6).Virtualchannelsidentiedbya31vcivalueandlater

called trash VCs are voluntarily left unconguredto allow theswitch to drop

cellsbelongingto acommunicationthat hastobedenied.

ATM Switch

PC Workstation

0

Internal

Network

1

5

6

4

1

Network

External

Fig.6.ATMSwitchConguration

IFTcardsallowonlyunidirectional owstobecontrolled.Thismeans that

incomingandoutgoing owshavetobeseparated.Thisoperationisparticularly

simplewhendealingwithaMonoModeFibberphysicalsupportsinceemission

andreceptionbbersarephysicallyseparated.Figure6showshowemissionand

ATM Cell

5

A

E

F

3

1

5

6

2

4

7

F

E

B

3

8

A

5

Fig.7.AnalysisExample

ThesecondpartisthecongurationoftheIFTstoprovidetheaccesscontrol

service. This conguration is done bythe manager. IFTs have been originally

designedtobemanaged remotelybyconcurrentmanagers.AsaresultanRPC

daemonhasbeendevelopedtoserialisecongurationrequeststotheIFTdriver.

On the manager side, a library gives access to conguration functions. This

library translates the local calls to remote calls on the Solaris PC. The

com-municationbetweentheworkstationandthePC aredonethroughadedicated

externalEthernetnetwork.

TheIFT analysis process is basedon thetrie memory([19]). Triememory

is especially interestingin orderto takeadvantageof theredundancy thatcan

befoundinaccess controlpolicies.Thecongurationof thisprocessreliesona

descriptionof thecommunicationsasaset oftrees. Each branch within atree

describesa4bitvaluethatcanbematchedduringtheanalysisprocess.Theroot

of each tree describesa gateby which to begin the treeanalysis. An example

ofanalysis isprovidedin gure7.Additionalinformation canbeprovided ina

nodetoallowtheanalysistojumpfromonetreetoanotherortoterminatethe

analysis and return theconnectionidentiers valuesthat haveto be modied.

Conguration functions allow the manager to build, update and remove this

set of treesand entries within agiven treewhile the IFTs are operating. The

translation between the information provided by the dynamic cell-level policy

generationprocessandtreescanbedoneasfollows:

{ Eachpossibleeldiscodedintoatree.Thevaluesdescribedbythesecurity

policyarethenslicedin4bitwordsandattributedtothenodesofthetree.

Rangedescribed by multiple conditionsonthesameeld canbedescribed

bygeneratingthenodesforeachpossiblewordinsidetherange.

{ An ANDoperation betweentwoconditionsontwodierent eldsis coded

asajump fromonetreetoanother.

action is coded by directing the frame to a trash virtual channel on the

switch. An ALLOW action is coded by leaving the connection identiers

eldsunmodied.

Preliminary experimental results ([15]) show that the use of trie memory

makesitpossibletostorethecompleteTCP/IPlevelaccesscontrolpolicyfrom

a well know French ISPin 2.8M 4bits words. This is far behind the capacity

ofthecurrentIFTprototypewhichis4M4bitswords.Additionalresults([16])

showthat theworstcasedelayintroduced bytheaccess controlprocessduring

thetestwas around1.7s.

4 Conclusion

In this article, we describe in detail how an ATM rewall can be constructed

byusingexisting components.ThisATM rewallhastheabilitytoprovidethe

access control service at the ATM, IP and transport levels at 622Mb/s while

maintainingtheQoSthat hasbeennegotiated.Aswecansee,ourapproachhas

thefollowingadvantages:

{ GoodaccesscontrolattheATMlevel.

{ SmallimpactontheQoSthankstoaboundeddelaycelllevelaccesscontrol

process.

{ Improvedaccesscontrolspeedatthecelllevel.

{ Is notsubjectto performance DoS attacks likeexisting cache based

archi-tectures.

{ Caneasilybeadaptedtoprovidetheaccesscontrolserviceforotherkindsof

ATM usage(LANE,MPOA,MPLS)withreducedsoftwaredevelopments.

Ourproposalcouldbeimprovedinthefollowingdirections:

{ Application level access control could be easily provided for applications

withnoqualityofservicerequirementsbyusingtheIFTstodirectthe ows

generatedbytheseapplicationstoaclassicalrewallwherethese owscould

beanalysedindepth.ThelterwouldhavetobemodiedtosendaQoS ag

tothemanageralongwiththesetof parameterscurrentlyused todescribe

theconnection.ThissolutionwouldalsoprovideananswertotheIPoptions

problem.

{ Themanager and the messagelter could be modied to provideltering

capabilitiesforother kindsofATM usagesuchasLANEmulation,MPOA

orMPLS.

{ Theaccesscontrolspeedcouldbeimproved.Ourindustrial partner is

TheauthorswouldliketothankallthepeoplethatareinvolvedintheCARAT

project,namelyYveslePapeAnthonyLucas,BenoitMartinandJean-Jacques

Maret at DGA, PierreRolin, Christian Duret, Joel Lattmannand Jean-Louis

SimonatCNETfortheirsupportandusefulcomments.

References

1. ISO, ISO7498-2:1989, Informationprocessing systems{OpenSystems

Intercon-nection{BasicReferenceModel{Part2:SecurityArchitecture,1989.

2. J. McHenry, P. Dowd, F. Pellegrino, T. Carrozzi, W. Cocks, An FPGA-Based

Coprocessor forATMFirewalls,inproceedingsofIEEEFCCM'97,April1997.

3. D. Newman, H. Holzbaur, and K. Bishop, Firewalls: Don't Get Burned, Data

Communications,March1997.

4. NationalInstitute ofStandardsand Technology,StandardSecurity Label for

In-formation Transfer, Federal Information Processing Standards Publication 188,

September1994.

5. J.Abusamra,ATMNetManagement:MissingPieces,DataCommunications,May

1998.

6. Keylabs inc., Firewall Shootout Test Final Report, Networld+Interop'98, May

1998.

7. J.Strassner,S.Schleimer,PolicyFrameworkDenitionLanguage,

draft-ietf-policy-framework-pfdl-00.txt,InternetEngineering TaskForce,November1998.

8. O. Paul, M. Laurent, S.Gombault, Manageable Parameters to improve Access

Control inATMNetworks,inproc.ofthe5thHPOVUAWorkshop,April1998.

9. M. Ranum, Anetworkrewall, inproc.of theWorldConference onSystem

Ad-ministrationandSecurity,1992.

10. TheATMForumTechnicalCommittee,ATMSecurity SpecicationVersion1.0,

February1999.

11. J.Xu,M.Singhal,Designofahigh-performanceATMFirewall,inproc.ofthe5th

ACMConferenceonComputer&CommunicationsSecurity,1998.

12. The ATM ForumTechnicalCommittee, ATM User-NetworkInterface

Specica-tion,Version3.1(UNI3.1),July1994.

13. B. Kowalski, Atlas Policy Cache Architecture, White paper, Storagetek Corp.,

1997.

14. CiscoCorp., LightStream1010MultiserviceATMSwitchOverview,1999.

15. M.Accarion,C.Boscher,C.Duret,J.Lattmann,Extensivepacketheaderlookup

atGb/sspeedforanapplicationtoIP/ATMmultimediaswitchingrouter,inproc.

oftheWTC/ISS2000Conference,May2000.

16. CentreNationald'EtudedesTlcommunications-FranceTelecom,IPFast

Trans-lator,FT.BD/CNET/DSE/SDL/226/CD, December1999.

17. C.Benecke,AparallelPacketScreenforHighSpeedNetworks,inproc.ofthe15th

AnnualComputerSecurityApplicationsConference,December1999.

18. T.V. Laksham, D. Stiliadis, High-Speed Policy-based Packet Forwarding Using

EÆcient Multi-Dimensional Range Matching, in proc. of ACM SIGCOMM'98,

September1998.

19. E. Fredkin,Trie Memory,Communicationsof the ACM, Vol3,September1960,