Traceability - LINX Best Current Practice Keith Mitchell Executive Chairman, London Internet Exchange UBM Conference, London 8th Sep 1998

Overview Background, History, Motivation Principles IP addresses Dial-up users Applications DNS

LINX Experiences LINX is UK national Internet Exchange Point (IXP) Represents 55 largest UK/EU ISPs 4 “non-core” activities include: –Content Regulation –UBM (“spam”) Regulation

LINX & Regulation Funding, and policy & management oversight of IWF Defines “good practice” (BCP), but only mandatory requirements concern IXP Becoming involved in network abuse –UBM, resource theft Traceability BCP has been work in progress for over a year –8 authors so far –nearly finished !

Internet Watch Foundation Voluntary funding from large ISPs directly, and small/medium via associations Operates hot-line for reporting illegal material Working on content rating schemes (INCORE project, ICRA)

Key IWF Principle UK ISPs supporting IWF are not held responsible for illegal content on their systems, provided: –it was placed there by customers –they have no prior knowledge of it –they take appropriate action when they do learn of it n.b This is an informal agreement, not upheld by UK law

Traceability Principle of who did what & when on the Internet Key element of making individuals responsible for their actions Rest of talk outlines contents of LINX “Best Common Practice” draft document for ISP industry

Uses of Traceability Finding out sources of: –Illegal content (e.g. paedophile material) –Denial of Service attacks –Unsolicited Bulk Messaging (“spam”) –Hacking, fraudulent access

Traceability in Practice Complete knowledge is 100% possible in theory but practice will fall short of this BCP document will define how to make practice closer to theory Traceability is currently exception –ideally the norm –legitimate anonymity an exception

Traceability Obstacles Vendor support Passing information between ISPs and carriers, e.g. –across national borders –caller id Unregistered trial etc accounts 3rd party relaying ( )

IP Addresses All Internet activity has to come from some IP address –Starting point of any tracing exercise Need to map from this through: –domain name system –one or more ISPs –authentication system –PSTN to user

IP Address Spoofing Need to ensure traffic is coming from where its source address claims - easy to fake Most applications require duplex communication, so spoof abuse scope limited: –Denial of Service attacks –“Single shot” attacks –TCP sequence number interpolation

Spoof Prevention Static packet filters: –between backbone and “edge” routers in ISP’s backbone –performance impact –hard to scale elsewhere, e.g. between providers Dynamic filters: –per-user per dial-in session More info in RFC 2267

Dial-up Users Use of per-session dynamic IP address allocation is efficient but makes traceability harder User accounts and access numbers common to many dial-in routers Need to reliably map from: –(IP address, time) to (user)

Dial-in Authentication RADIUS authentication logs usually have info required, but: –need time synchronisation (NTP) –records can be lost (UDP) –vendor record format variations Alternatives include: –syslog, dynamic DNS, finger/telnet, SNMP

Unregistered Users e.g. –free trials –“pay as you go” services –public access terminals Pose particular traceability problems but there are ways to offer these services with safeguards

De-Anonymising Users Credit card check Voice phone call back Fax phone call back Avoid shared accounts Digital certificates Caller Id or CLI

Caller Id (CLI) Ideally phone number being used to make modem call passes through PSTN carriers and dial-in router to ISP’s logfiles Some issues in practice: –carriers –router vendors –users

Caller Id Issues Not all carriers present full CLI –regulatory intervention needed ? Not all dial-in routers: –accept or log CLI –differentiate withheld vs unavailable ISPs who are not carriers get user (possibly modified) CLI rather than network CLI

“Pay as you go” Services e.g. BTclick, FreeServe, C&W Need to be able to: –require and log CLI –block payphone, international, prepaid calls –maintain frequent abuser phone number blacklist –identify IP address ranges used for this

Traceability Very easy to make untraceable via fake headers Default config of many MTAs dumb in this respect Some routine precautions can tackle this Modern MTAs which are wise to this are available

MTA Config Make sure actual IP addresses are stamped on headers Disable 3rd-party relaying ! Consider using SMAP, Exim MTAs Source filter which IP addresses can connect to SMTP port DNS verification –valid ? –forward/reverse match ?

USENET News Servers Always add X-NNTP-Posting-Host: header Restrict posting from customer addresses only Heavily restrict use of mail2news –Always add X-Mail2news: header Importance of synchronised & verified time/date stamping

Domain Name Servers in-addr address to name mapping critical when tracing important to ensure server security in theory dynamic DNS update could insert user name into reverse lookup for session duration - hard in practice

BCP Status Currently in final draft form Limited distribution for consultation to interested parties Contributions still welcome ! Full publication end Nov –via

Work to be done New Sections: –Logging –Inter-provider issues –IRC & “chat” More details on: –Domain name service –IP spoofing, filtering –“pay as you go” services Corrections, improvements

Conclusions You can’t solve the whole problem..but straightforward measures can make a big difference Legal protection of legitimate users’ privacy must be addressed The industry can take a responsible lead through co-operation