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

• 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 - 0845 600 8844
• Working on content rating schemes
  (INCORE project, ICRA)
• http://www.internetwatch.org.uk
       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 (e-mail)
            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
     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
        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 ?
  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 http://www.linx.net
       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