t-110.5116 zfilters - stateless - aalto university research, nomadiclab 4.10.2010 maanantaina 4....

Slide title48 pt

Slide subtitle 30 pt

T-110.5116zfilters - stateless multicast forwarding

Petri Jokelaericsson research, Nomadiclab4.10.2010

maanantaina 4. lokakuuta 2010

Slide title 32 pt

Text 24 pt

Bullets level 2-520 pt

›!"# $%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~¡¢£¤¥¦§¨©ª«¬®¯°±²³´¶·¸¹º»¼½ÀÁÂÃÄÅÆÇÈËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿĀāĂăąĆćĊċČĎďĐđĒĖėĘęĚěĞğĠġĢģĪīĮįİıĶķĹĺĻļĽľŁłŃńŅņŇňŌŐőŒœŔŕŖŗŘřŚśŞşŠšŢţŤťŪūŮůŰűŲųŴŵŶŷŸŹźŻż�Ž�žƒȘșˆˇ˘˙˚˛˜˝ẀẁẃẄẅỲỳ–—‘’‚“”„†‡•…‰‹›⁄€™−≤≥fifl

Do not add objects or text in

the footer area© Ericsson AB 2009 | 4.10.2010

CONTENT

› Information centric networking› Stateless Multicast forwarding

– zFilters - the basic solution– Enhancements

› Security features› Applications of zFilters


Slide title48 pt


Information centric networking


Slide title 32 pt

Text 24 pt





Background

› Most of the presented work has been done in the PSIRP EU FP7 project

– Information centric networking– Publish/Subscribe for distributing data– zFilter based forwarding– www.psirp.org– The project ended on 30.9.2010

› Work continues in PURSUIT (1.10.2010 ->)– www.fp7-pursuit.eu

› Same topics also in Finnish Future Internet programme – part of ICT-SHOK, www.futureinternet.fi

› Content centric networking is a “hot topic”– E.g. Van Jacobson’s CCN


http://www.psirp.org




http://www.futureinternet.fi

http://www.futureinternet.fi

Slide title 32 pt

Text 24 pt





Clean slate approach

› Think DATA as the first class citizen– Users interested in data, not in the hosts– Publisher’s identity important– Topic based publish/subscribe

PublisherShop


Slide title 32 pt

Text 24 pt






› Data published once, received multiple times– Asynchronous multicast, timely separated requests– Data delivery from caches instead of the actual source

› Caching becomes an essential function Publisher

Shop09:3012:14

17:30 04:15

Data

Printing


Slide title 32 pt

Text 24 pt






› DDoS problem in current networks– Network serves the sender– Unwanted traffic against the receiver’s will– Target: Data delivery only when explicitly requested

Unwanted traffic


Slide title 32 pt

Text 24 pt





RTFM architecture

› Rendezvous - matching publish and subscribe events

Rendezvous Rendezvous Rendezvous

Topology Topology Topology

Publisher fwd fwd fwd fwd fwd fwd Subscriber

Publ

ish (I

D)Subscribe (ID)

Matching


Slide title 32 pt

Text 24 pt





RTFM architecture

› Rendezvous - matching publish and subscribe events› Topology - network topology knowledge, path creation




Publ

ish (I

D)Subscribe (ID)

Matching

Path creation


Slide title 32 pt

Text 24 pt





RTFM architecture

› Rendezvous - matching publish and subscribe events› Topology - network topology knowledge, path creation› Forwarding - fast delivery




Publ

ish (I

D)Subscribe (ID)

Matching

Path creation

Data delivery

FID


Slide title48 pt


zfilters for packet forwarding


Slide title 32 pt

Text 24 pt





Publication delivery

› Topic delivery with IP addresses– Problem with the delivery model; sender is always in control– Firewalls (and other middle-boxes) needed for blocking unwanted

traffic

“To Wall Street”


Slide title 32 pt

Text 24 pt






› Topic delivery with IP addresses– DDoS still possible

“To Wall Street”


Slide title 32 pt

Text 24 pt






› Instead of naming end-hosts, we can name the data– But how to deliver the data?

› For each topic, we have to – Locate the actual pieces– Create a way to deliver the data– Physically forward the required pieces to the subscriber

“D”

??

“I want A”

A1

A2

A3

“A”


Slide title 32 pt

Text 24 pt






› Routing based on Topic ID: State in the routers– 10^11 topics => enormous amount of state in forwarders– State need to be changed based on subscriptions– => Not scalable

Topic A => 1Topic B => 3,4Topic C => 1,2Topic D => 2Topic E => 4.. .. ..

??

A

X

New forwarding info (AGAIN): E => 3 D => 1,2 C => REMOVE

Post office


Slide title 32 pt

Text 24 pt






› How about storing the state in the packet?– Define the path from the source to the destination

› IP: include all visited IP addresses in a list- A long list of IP addresses, and we do not solve the DDoS

› Without IP: Include all visited nodes in the packet- Long list of Node IDs!

A: {HOP1; HOP2;HOP3; HOP4;

HOP5; ... HOP 40}


Slide title 32 pt

Text 24 pt





Let’s take a short visit to 1970 and check what Burton Howard Bloom did at that time


Slide title 32 pt

Text 24 pt





Bloom filters

› Probabilistic data structure, space efficient› Used to test if an element is a member of a set

0000000000 Hash 1

Hash 2

10-bit Bloom Filter


Slide title 32 pt

Text 24 pt





Bloom filters

› Inserting items– Hash the data n times, get index values, and set the bits

0010000010

Data 1

Hash 1Hash 2

Hash 1(Data1) = 9Hash 2(Data1) = 3

10-bit Bloom Filter


Slide title 32 pt

Text 24 pt





Bloom filters

› Inserting items– Hash the data n times, get index values, and set the bits

0010001010

Data 1

Data 2Hash 1Hash 2


10-bit Bloom Filter


Slide title 32 pt

Text 24 pt





Bloom filters

› Test if “Data 1” has been inserted in the BF– All corresponding bits are set => positive response!

0010001010

Data 1

Hash 1Hash 2

VerifyingHash and check if set


10-bit Bloom Filter


Slide title 32 pt

Text 24 pt





Bloom filters

› Test if “Data 3” has been inserted in the BF– All bits do not match => negative response

0010001010

Data 3

Hash 1Hash 2



10-bit Bloom Filter


Slide title 32 pt

Text 24 pt





Bloom filters

› False positive: “Data 4” was never added

0010001010

Data 4

Hash 1Hash 2



10-bit Bloom Filter


Slide title 32 pt

Text 24 pt





So... what is the relation between Bloom Filters and packet forwarding in our case?


Slide title 32 pt

Text 24 pt






› How about storing the state in the packet and compress it using Bloom filters?

A: {HOP1; HOP2;HOP3; HOP4;

HOP5; ... HOP 40}A: {Bloom Filter}


Slide title 32 pt

Text 24 pt





Link IDs

› No names for nodes– Each link is identified with a

unidirectional Link ID

› Link IDs– No need to hash anything, we

can generate the 1-bits otherwise– Size e.g. 256 bits of which 5 bits

set to 1› 2 x the size of an IPv6 addr› Statistically unique

A

D

B C

0 1 0 0 0 1 0 0 1 1 0 0 0 0 1 1 0 0

A->BB->C

A->BB->C


Slide title 32 pt

Text 24 pt





Generating Link IDs

› Locally generated– “Random bits”– Based on some node information

› Centrally controlled– Link IDs given by the “AS owner”

› Easier to control network behavior in forwarding

– Give an algorithm to generate LID from some node information

A

D

B C

0 1 0 0 0 1 0 0 1 1 0 0 0 0 1 1 0 0

A->BB->C

A->BB->C


Slide title 32 pt

Text 24 pt





Link IDs and forwarding Bloom filters (zFilters)

› Strict Source Routing– Create a path, collect all Link IDs– Include all path’s or tree’s Link

IDs into a Bloom filter› Multicasting supported

– Take multiple outgoing links from one router

› “Stateless”– Only Link IDs stored on the router

› ρmax = maximum rate of “1”s

A

D

B C

0 1 0 0 0 1 0 0 1 1 0 0 0 0 1 1 0 0

A->BB->C

A->BB->C


Slide title 32 pt

Text 24 pt





Creation of the zFilter

› zFilter creation– We assume knowledge of the network

topology and Link IDs– Topology information

› Currently e.g. OSPF or PCE › Use existing protocols

› Once created, the zFilter is given to the data source

› The source adds the zFilter to outgoing data packets

› Data ALWAYS forwarded to the correct destination

– False positives add some falsely routed traffic

00101001

Topology: zFilter formation

0000100100100001

Source node

OR

Topic DATA00101001

LID1 LID2


Slide title 32 pt

Text 24 pt





Forwarding decision

› Forwarding decision based on binary AND and comparison– zFilter in the packet matched with all outgoing Link IDs– Multicast: the zFilter contains more than one outgoing links– forward if: ((zFilter AND LID) XOR LID) = 0

zFilter

Link ID

& =

zFilterYes/No

Interfaces


Slide title 32 pt

Text 24 pt





Using Link Identity Tags (LIT)

› Better false positive rate with a simple trick– Define n different LITs instead of a single LID– LIT has the same size as LID, and also k bits set to one– [Power of choices]

› Route creation and packet forwarding– Calculate n different candidate zFilters– Select the best performing zFilter, based on some policy

Link IDLIT 1LIT 2LIT n

Link IDLIT 1LIT 2LIT n

Candidate zFilterzFilter 1zFilter 2zFilter n

Host 1: Iface out Host 2: Iface out


Slide title 32 pt

Text 24 pt





Using Link Identity Tags (LIT)

BF

LIT1

& =

Yes/No

LIT2

LITn

d

d? & =

& =

BFd

Interfaces


Slide title 32 pt

Text 24 pt





zFilter collection

› During packet traversal, the reverse zFilter can be easily generated

– Add a field in the packet for collected zF– All routers forwarding the packet add the incoming LID to the field– Once the packet arrives to the destination, the collected zF can be

used to forward data to the reverse direction

Node 2 IF 2-2

Interface Link IDIF 1-1 00110000IF 1-2 00001001

IF 2-1

DATA

Node 1

zF

IF 1-2IF 1-1

zFC

Interface Link IDIF 2-1 01010000IF 2-2 10000010

Matching for outgoingzFC = zFC OR LID1-1


Slide title48 pt


Performance


Slide title 32 pt

Text 24 pt





Forwarding efficiency

› Simulations with– Rocketfuel– SNDlib

› Forwarding efficiency with 20 subscribers

– ~80%


Slide title 32 pt

Text 24 pt





Forwarding efficiency

› Simulations with– Rocketfuel– SNDlib

› Forwarding efficiency with 20 subscribers

– ~80%– LIT Optimized: 88%

n


Slide title 32 pt

Text 24 pt





changing zFilter sizeAS3967: 79 nodes, 147 bi-directional links


Slide title 32 pt

Text 24 pt





Forwarding speed

› Measured on a NetFPGA › Results

– Latency slightly smaller when compared to IP forwarding

– zF latency stays constant, independent of the network size

Path Avg. latency Std dev.Plain wire 94 µs 28 µsIP router 102 µs 44 µszFilter 96 µs 28 µs


Slide title48 pt


A topology example


Slide title 32 pt

Text 24 pt





OSPF› Link-state information exchanged with OSPF messages

– All routers share the same Link-state information– Used to build forwarding tables

ER

Link-State DatabaseWn = weight of the link

R1

R2R3

R5

R6 R8

R4

R7

R3R4

R7 R8

R1

R2

R5

R6

ER

R1 R2 R3 R4R1 W1 W2R2 W1R3 W2 W3R4 W3

From

To

N1


Slide title 32 pt

Text 24 pt





OSPF Areas

OSPF area 0 (Backbone)

OSPF area 2

OSPF area 1

ER

R1

R5

R3

R6

R7

N1

N2

› Full Link-state information distributed only inside an area– From other areas, only aggregated information

Laptop 1R4

R1 R2 R3R1 W1 W2R2 W1R3 W2

N1 W3N2 W4

From

To

R2


Slide title 32 pt

Text 24 pt





Extending OSPF

OSPF area 0 (Backbone)

OSPF area 2

OSPF area 1

ER

R1 R2

R5

R3

R6

R7

N1

N2

› Include Link ID into OSPF messages– Or alternatively, use a known algorithm to generate LID

› R4 can calculate zF for e.g. packets going to N1:– zF = L1 | L2 | L3

R3

R4

R1

R2 R5

Laptop 1R4

L1

L2

L3


Slide title 32 pt

Text 24 pt





Using OSPF based topology manager

› OSPF directly (as described)– OSPF uses IP

› PCE (Path Computation Element)– OSPF based, centralized computation– (G)MPLS uses PCEs

› In PSIRP– Topology manager works in a similar way as OSPF– No IP

› Node and link information published using well-known Pub ID› All nodes subscribed to this Pub ID


Slide title48 pt


Enhancements


Slide title 32 pt

Text 24 pt





Issues

› Loops› Scalability› Rerouting

– How to bypass a failing router› Attacks

– Security related issues


Slide title 32 pt

Text 24 pt





Avoiding loops

› Lowering the amount of loops– Instead of fixed d determining the used LIT, change the d e.g. with

d=(d+1) MOD e– In case of a loop, the packet will have the same d only if the loop is

e hops long– Simple, stateless solution

Link IDLIT 1LIT 2LIT 3

Host 1Link ID

LIT 1LIT 2LIT 3

Host 2Link ID

LIT 1LIT 2LIT 3

Host 3

zFilter


Slide title 32 pt

Text 24 pt





Scalability: Virtual trees

› Popular paths can be merged into virtual trees– A single Link ID for the tree– Additional state in the forwarding nodes– Increase scalability

› A virtual tree is not bound to a certain publication delivery– E.g. a single tree for all AS transit traffic

B

F

C D

0 0 1 0 1 0 0 0 1

A E

Virtual B->C->D->E


Slide title 32 pt

Text 24 pt





Fast reroute - add alternative path to zfilter

› Node B maintains backup path information › In case of broken link, add backup path

– Increases temporarily the false positive probability until a new path is calculated at the topology manager

– No additional signaling

B

F

C

D

Add backup path:zF = zF | LBF | LFD


Slide title 32 pt

Text 24 pt





Fast reroute - Use virtual Trees

› zFilter unmodified› Activate backup path in case of node failure

– Adds signaling

B

F

C

D

Link broken, signal the activation of thebackup path to F

Text

LID1

Virtual tree: LID1

Virtual tree: LID1


Slide title 32 pt

Text 24 pt





Backward compatibility

› End-hosts legacy IP› With OSPF, R1 can calculate zFs to R2 & R3

– IP-over-zFilter

IP zFilter IP

zFilter

R1 R2

R3


Slide title48 pt


Security features - zformation


Slide title 32 pt

Text 24 pt





Forwarding security

› zFilter security weaknesses (static LID/LITs)– zFilter replay attacks

› Sending data with the same zFilter– Computational attack

› Collect zFilters › Correlate zFilters to learn link IDs

– Traffic injection attack› Using existing zFilter, send data from the middle of the path


Slide title 32 pt

Text 24 pt





Secure forwarding

› Goal: to ensure (probabilistically) that hosts cannot send un-authorized traffic

› Solution (z-Formation): Compute LIT in line speed and bind it to

– path: in-coming and out-going port– time: periodically changing keys– flow: flow identifier (e.g. IP 5-tuple / content id)


Slide title 32 pt

Text 24 pt





Secure case: z-Formationaka Secure in-packet BFs

› Form LITs algorithmically– at packet handling time– LIT(d) = Z (I , K (t), In, Out, d),

› Secure periodic key K› Input port index› Output port index

› Flow ID from the packet, e.g.– Information ID– IP addresses & ports

› d from the packet

ZIN port #

OUT port #

K(t)

& =

LIT(d)

yes/no

Flow ID

BFd


Slide title 32 pt

Text 24 pt





Security properties

› zFilter works both as a forwarding ID and a capability– To send, a host needs to know or guess a valid zFilter

› If the zFilter is bound only to the outgoing port– Traffic injection possible– Correlation attacks possible

› Solution: bind to the incoming and outgoing ports– Traffic injection difficult (due to binding to incoming port)

› Very hard to construct one without knowing keys along the path– Correlation attacks possible only for a given flow ID

› Bound to the packet stream (flow ID)› Need a cryptographically good Z algorithm


Slide title 32 pt

Text 24 pt





Injection attacks

› Assuming attacker knows a zFilter passing at h hops distance from attacker

› Left y-axis shows the probability of a single packet reaching target for various fill factors

› Right y-axis shows the average number of attempts for one successful injection with probability 0.5

10-10

10-8

10-6

10-4

10-2

100

1 2 3 4 5 6100

102

104

106

108

1010

1012

Atta

ck s

ucce

ss p

roba

bilit

y

Num

ber o

f atte

mpt

s x

(m

ax =

0.5

)

Attack path length (h)

max = 0.45max = 0.50max = 0.55

Pr = 0.5


Slide title 32 pt

Text 24 pt





Discussion

› Replay attacks: limited to the key lifetime – As zFilters are tied to periodically changing keys (K(t)), one per

node, the capabilities become expirable› Brute force attack: “Best” attack strategy

– Assuming attack traffic of 1M pps (1Gbps / 1000 bits pp)> 40min to guess (with Pr=0.5) one 5-hop working zFilter (which is only usable for single host)

› Re-keying time?– Trade-off between minimizing duration of unwanted traffic vs.

overhead of zFilter renewal e.g., 1 min enough to complete transactional traffic + protect short paths

› Attack detection and mitigation:– fpr increase: triggers detection plus

e.g. blacklist mechanism on FlowID


Slide title48 pt


applications


Slide title 32 pt

Text 24 pt





Data centers

› zFilters only in the internal network› Easier to modify the routing in the network

– E.g. route packets via certain services: Load balancing, monitoring...– Binding the flow to input and output ports allows flexible path control

at the ingress point

RouterIngress router

Externalnetwork (IP)

Monitoring

Filtering

Data center network - zF based forwardingMonitoring + filtering -> zF-1Filtering -> zF-2

Decision for zF


Slide title 32 pt

Text 24 pt





(G)MPLS - Generalized multiprotocol label switching

› Evolution: MPLS->MPLS-TE -> GMPLS› (G)MPLS is a rich set of protocols

– Setting up Label Switched Paths– Forwarding on the Label Switched Paths– Traffic Engineering, resiliency (e.g. fast reroute)– Enabler of VPN services– Control plane for many different technologies

PEPPE

IP Payload IP Payload Label1 IP Payload Label2 IP Payload

Provider Edge Router Provider Router Provider Edge Router

Push label Switch label Pop label


Slide title 32 pt

Text 24 pt





MPSS - Multiprotocol stateless switching

› Advantages over label switching– There is not necessarily need for signaling– In simpler case, no state required– Multicast support (setup, maintenance) much simpler than with

(G)MPLS

PEPPE

IP Payload IP Payload zF IP Payload zF IP Payload

Provider Edge Router Provider Router Provider Edge Router

Push zF zF forwarding Pop zF


Slide title 32 pt

Text 24 pt





Multicast VPN with MPSS

› Effective support of point-to-multipoint communication› The bandwidth efficiency vs. Multicast state trade-off

eliminated– (Though longer header sizes)

› With zFilters: no multicast states, and acceptable bandwidth efficiency up to ~20 PEs

PE

PE PE

PE

CE

CE

CE

P P

CE

CE

CE CE


Slide title48 pt


Prototyping and future


Slide title 32 pt

Text 24 pt





zFilter implementation

› Open source releases– Forwarding implemented on netFPGA, FreeBSD– End-host implementation on FreeBSD– Download: www.psirp.org

› Click modular router implementation

Publisher -

FreeBSD

NetFPGA

Subscriber -

FreeBSD

Subscriber -

FreeBSD

NetFPGA


Slide title 32 pt

Text 24 pt





Future work

› PURSUIT – zFilters are used in forwarding – E.g. data centers

› UNICAMP - Brazil– Working also on data centers and zFilter based forwarding

› ICT-SHOK– Next phase planning going on


Slide title 32 pt

Text 24 pt





Future work

› One track in PURSUIT: Optical networks– In optical networks, packet buffering is very limited

› Short delays by looping– IP based forwarding

› Routing table lookups are slow› ->OEO conversion

– MPLS › Can be done in all-optical routers› Requires label swapping at each of the nodes

– zFilters seems to be suitable for all-optical forwarding› All-optical switch may be simpler than with MPLS


t-110.5116 zfilters - stateless - aalto university research, nomadiclab 4.10.2010 maanantaina 4....

Documents