1 / 27

Traceability - LINX Best Current Practice

Traceability - LINX Best Current Practice. Keith Mitchell keith@linx.net 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.

sorcha
Télécharger la présentation

Traceability - LINX Best Current Practice

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Traceability - LINXBest Current Practice Keith Mitchell keith@linx.net Executive Chairman, London Internet Exchange UBM Conference, London 8th Sep 1998

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

  3. 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

  4. 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 !

  5. Internet Watch Foundation • Voluntary funding from large ISPs directly, and small/medium via associations • Operates hot-line for reporting illegal material - 0845 600 8844 • Working on content rating schemes (INCORE project, ICRA) • http://www.internetwatch.org.uk

  6. 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

  7. 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

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

  9. 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

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

  11. 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

  12. 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

  13. 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

  14. 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)

  15. 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

  16. 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

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

  18. 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

  19. 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

  20. “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

  21. E-Mail Traceability • Very easy to make e-mail 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

  22. E-mail 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 ?

  23. 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

  24. 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

  25. BCP Status • Currently in final draft form • Limited distribution for consultation to interested parties • Contributions still welcome ! • Full publication end Nov • via http://www.linx.net

  26. 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

  27. 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 throughco-operation

More Related