stephan kubisch , harald widiger , peter danielis , jens schulz, dirk timmermann

Stephan Kubisch, Harald Widiger, Peter Danielis,Jens Schulz, Dirk Timmermann

{stephan.kubisch;peter.danielis}@uni-rostock.de

University of Rostock Institute of Applied Microelectronics and Computer Engineering

Thomas Bahls, Daniel Duchow

{thomas.bahls;daniel.duchow}@nsn.com

Nokia Siemens NetworksBroadband Access Division

Greifswald, Germany

MIT 2008 Spam Conference, Cambridge, MA, USA, March 27-28

Complementing E-Mails withDistinct, Geographic Location Information

in Packet-switched IP Networks


2

Complementing E-Mails with Distinct, Geographic Location Information in Packet-switched IP Networks

Outline

1. Introduction & Motivation2. The General IPclip Mechanism3. Anti-Spam Framework using IPclip

1. Modifying the E-Mail Header2. A Typical Mail Flow3. Requirements and Constraints4. Advantages

4. Summary


3

Complementing E-Mails with Location Information in Packet-switched IP Networks

1. Introduction & Motivation

We do have a spam problem!

• Lack of user trustworthiness in the mass-medium Internet

Spam: Masses of unsolicited bulk e-mails delivered by SMTP

• What can be done against spam? – DetectTracePrevent

• Available anti-spam tools trigger on e-mail and header content

• Data can be forged: Spammers lie!

• Anti-spam examples– DomainKeys Identified Mail (DKIM) – Sender Policy Framework (SPF)– SpamAssassin– … and many more

No 100% solution out there!




Public Switched Telephone Network• Line-switched• Call number identifies access line and an address• Direct interrelationship with location information (LI): Trust-by-Wire!

Internet• Packet-switched• IP addresses are ambiguous! • No interrelationship with LI: No Trust-by-Wire (TBW)! • Trust-by-Authentication (TBA) to provide user trustworthiness?

SMTP and the Internet lack both TBW and TBA!How do we restore the user's belief in e-mail services?

Public Switched Telephone Network vs. Internet

4


5


Outline



4. Summary


6


Verified Location Information

GPS

GPS

UserUnverified Location Information

No Location Information

GPS

Access Node with IPclip @ Pos (x,y)

Internet

2. The General IPclip Mechanism

• IPclip = IP Calling Line Identification Presentation• Location information (e.g., GPS) is added to each IP

packet as IP option Location information in IP– Either by the user or by the access node of an access network

IPclip is used to provide a useful degree of TBW in IP networks


7



• IP header can contain IP options

• IP options show a type-length-value structure• Location information as value part of an IP option

What kind of location information do we use?

IP Options...

IP Header

UDP, TCP, ...

Latitude (cont.) LongitudePort Access Node ID

IP Type IP Length LatitudeIPclip Type Status FieldAccessPadding


8



• Access node is the 1st trustworthy network element– User provided location information solely verified here– Access port + access node ID as complementary information

Access network most reasonable place for adding/verifying LI

Access Network

Linecards

Aggregation

Broadband AccessServer

Metro/Core Network

ISP

IPclip

UserAccess Node (ID = 0xab)

...Access Ports


9



• User provided LI trustworthy if within access node‘s subscriber catchment area (SCA)

• IPclip on access node sets flags in status field depending on LI‘s trustworthiness

Access Node's SCA (normalized coords)

Using IPclip for ensuring trustworthy location information (LI) in IP

(0;0) (1;0)

(0;1) (1;1)

Alice sends Position (0.2;0.7)

Eve sends Position (1.2;1.4)

Eve’s Flags = network provided, untrusted

Alice’s Flags = user provided, trusted

Access Node @ Position (0.5;0.5)

Alice @ Position (0.2;0.7)

Eve @ Position(0.3;0.2)

Status Field

Removal Flag

Peering Flag

Source Flag

Trustability Flag


10



• User provided LI trustworthy if within access node‘s subscriber catchment area

Source /Trustability

Interpretation Status Flags

User provided / untrusted

User LI incorrect.

00

User provided / trusted

User LI correct. 01

Network provided / untrusted

User LI incorrectand replaced.

10

Network provided / trusted

No user LI. AN‘s LI added.

11

Access Node's SCA (normalized coords)

Using IPclip for ensuring trustworthy location information (LI)

(0;0) (1;0)

(0;1) (1;1)

Alice sends Position (0.2;0.7)

Eve sends Position (1.2;1.4)

Eve’s Flags = network provided, untrusted

Alice’s Flags = user provided, trusted

Access Node @ Position (0.5;0.5)

Alice @ Position (0.2;0.7)

Eve @ Position(0.3;0.2)


11


Outline



4. Summary


12


3. Anti-Spam Framework using IPclip

• IPclip adds location information on layer 3 as IP option• Mail transfer agents (MTAs) terminate IP We need location

information on application layer (SMTP)The first MTA copies location information in IP to e-mail

header as location information in SMTPFrom - <timestamp> X-IPCLIP-STATUS: 1100 X-IPCLIP-TYPE: GPS X-IPCLIP-LI: <LONGITUDE;LATITUDE> X-IPCLIP-PORT: X X-IPCLIP-AN: A X-IPCLIP-MTA: MX.SENDERHOME.NET [86.165.10.2] Return-Path: <[email protected]> Received: from ...

How to use IPclip and location information for fighting spam?


13


3. Anti-Spam Framework using IPclipTypical mail flow between Alice & Bob (same provider network)

BobAlice1

5

4

3

2

MTA1

MTA2A

B

Access Node(IPclip-capable)

User Host

Mail Transfer Agent(IPclip-capable)


14



• These 4 different possibilities regarding the existence of location information (LI) in IP and LI in SMTP represent our framework

LI in IP LI in SMTP Interpretation

First MTA Insert LI in SMTPE-mail originates from different provider domainNot first MTA Forward e-mailSomething went wrong Treat with special care

4 cases can be distinguished when an e-mail arrives at an MTA

2

5


15


3. Anti-Spam Framework using IPclipTypical mail flow between Alice & Bob (same provider network)

BobAlice1

5

4

3

2

MTA1

MTA2A

B


User Host



16



• Fully IPclip-terminated domain, e.g., a self-contained provider network– IPclip is mandatory at all access nodes

• IPclip-capable IP stack in relevant network devices– MTAs must understand location information (LI) in IP– MTAs must copy LI in IP to e-mail header as LI in SMTP– Mail User Agents or anti-spam tools must understand LI

in SMTP to take advantage of it

Requirements and constraints for IPclip in this use case


17



• IPclip supports removal of location information (LI) in IP

• IPclip‘s status field contains removal flag (RF)

– RF indicates removal of LI in SMTP at recipient‘s MTA– Source and trustability flag not removed Trigger for anti-

spam mechanisms without revealing LI• Use an encrypted format for LI

Privacy issues – revelation of sensitive user LI?

Status Field

Removal Flag (RF) Peering Flag Source Flag Trustability Flag


18


3. Anti-Spam Framework using IPclipAdvantages

Beneficial Aspect Explanation Benefit

1. Tracing Spam Tracing based on geographic location information

More exact than WHOIS lookups of IP addresses

2. Classifying Spam Status flags are additional, trustworthy triggers for anti-spam tools like SpamAssassin

More reliable classification of spam


19


Outline



4. Summary


20


4. Summary

• IPclip adds location information (LI, e.g., GPS) to each IP packet

1. More precise tracing of spam by means of LI

2. More reliable classification of spam by means oftrustworthy status flags

• Conceptual anti-spam framework using IPclip

• Benefits of the proposed approach

• IPclip guarantees LI’s trustworthiness (Trust-by-Wire)

• IPclip-capable MTAs copy LI in IP to e-mail header as LI in SMTP


21


Thank you! Any questions?

[email protected]://www.imd.uni-rostock.de/networking




Trust-by-Wire (TBW)• Trusted interrelationship between a user and his/her

geographic location• Example: Given in Public Switched Telephone Network (PSTN)

Trust-by-Authentication (TBA)• Verification of user identity by means of safe information, e.g.,

passwords• Example: Applied in the Internet

Trust models for garantueeing trustworthiness of a user

22


23


3. Anti-Spam Framework using IPclipPossibilities for an e-mail sender in adding location information

False location but outside the SCA

(1.2;1.4)

user provided/trustedA (0.3;0.2), Port x

Eve

IPclip on Access Node A@ A (0.5;0.5)

network provided/untrustedA (0.5;0.5), Port x

network provided/trustedA (0.5;0.5), Port x

user provided/trusted A (0.6;0.6), Port x

True location(0.3;0.2)

No location

False location butinside the SCA

(0.6;0.6)

LI seems to be not suspicious

Alice

Untrusted LI is highly suspicious(SMTP 2/4/5xx)

?

First MTA en Route

HostForward modifiede-mail to

recipient’s MTAor next hop

LI may be suspicious

user provided/untrustedA (1.2;1.4), Port x

1

2

3

4


24



• Yes, but forged LI in SMTP can be detected• First MTA knows it is the first one

– LI in SMTP options may not exist at the first MTA– LI in IP only exists at first MTA

Can location information (LI) in SMTP be forged?


25


Mail flows between Alice, Bob & Peter (different provider nets)

Bob

Peter

Alice

Provider Domain 1

Provider Domain 2

MTA1 B

MTA3

A

C

MTA4

MTA2

D

E

PeeringFlag

Border Gateway(IPclip-capable)


User Host


Status FieldRemoval Flag Peering Flag Source Flag Trustability Flag


26


Comparison DKIM, SPF, IPclipWhy IPclip, differences/benefits compared to DKIM, SPF

DKIM SPF IPclip

Performance impact associated with

scanning, encrypting and decrypting

messages

Internet domain owner must publish a complete list of every allowed network path

Packet processing in wire speedNo „forwarding problem“

No 100 % spam protection

No 100 % spam protection

Another trigger for classifying/tracing spam

stephan kubisch , harald widiger , peter danielis , jens schulz, dirk timmermann

Documents