T NetFPGA prototype of zfilter forwarding. Petri Jokela ericsson research, Nomadiclab

Transcription

1 T NetFPGA prototype of zfilter forwarding Petri Jokela ericsson research, Nomadiclab

2 CONTENT Information centric networking Reasoning, background Forwarding with In-packet Bloom Filters Basic idea Enhancements Security Implementation The NetFPGA router and reference implementation Implementing zfilters on a NetFPGA

3 Information centric networking

4 Background Most of the work has been done in PSIRP EU FP7 project Information centric networking Publish/Subscribe for distributing data Currently, the work is going also in the Future Internet programme, as part of ICT-SHOK

5 Clean slate approach DATA as the first class citizen Users interested in data, not in the hosts Topic based publish/subscribe DDoS problems in current networks Network serves the sender Unwanted traffic can be sent against the receiver s will Target: Data delivery ONLY when explicitly requested Data published once, received multiple times BUT from different locations and at different times Asynchronous multicast: timely separated requests Data delivery from caches instead of the actual source Caching becomes an essential function in the network

6 RTFM architecture Rendezvous - matching publish and subscribe events Publish (ID) Matching Rendezvous Rendezvous Rendezvous Topology Topology Topology Subscribe (ID) Publisher fwd fwd fwd fwd fwd fwd Subscriber

7 RTFM architecture Rendezvous - matching publish and subscribe events Topology - network topology knowledge, path creation Publish (ID) Matching Rendezvous Rendezvous Rendezvous Path creation Topology Topology Topology Subscribe (ID) Publisher fwd fwd fwd fwd fwd fwd Subscriber

8 RTFM architecture Rendezvous - matching publish and subscribe events Topology - network topology knowledge, path creation Forwarding - fast delivery Matching Publish (ID) FID Rendezvous Rendezvous Rendezvous Path creation Topology Topology Topology Subscribe (ID) Publisher fwd fwd fwd fwd fwd fwd Data delivery Subscriber

9 In-packet bloom filters for packet forwarding

10 Topic based pub/sub: how to deliver data? Routing based on Topic ID 10^11 topics => enormous amount of state in forwarders State need to be changed based on subscriptions => Not scalable 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! Compress the list into a Bloom filter! - Path not visible

11 Bloom filters Probabilistic data structure, space efficient Used to test if an element is a member of a set Possibility for false positives Inserting items Hash and set bits Data 1 Data Verifying Hash and check if set Hash 1 Hash 2 Data 1

12 Link IDs and forwarding Bloom filters (zfilters) No names for nodes Each link is identified with a unidirectional Link ID Link IDs Statistically unique Periodically changing Size e.g. 256 bits Local or centrally controlled Source routing Include all Link IDs into a Bloom filter Multicasting supported Stateless ρmax = maximum amount of 1 s A A->B A->B B->C zf: A->B->C B D B->C C

13 Creation of zfilters zfilter creation Assumes knowledge of the network topology Assumes knowledge of the link IDs on the path Topology information Currently e.g. OSPF or PCE (Path Computation Element) for (G) MPLS zfilter creation can be merged with the existing protocols Once created, the zfilter can be assigned to the data source Pure zfilter based forwarding in the whole network can be put into the packet in a network router Makes it possible to run IP from the end-host

14 Forwarding decision Forwarding decision based on binary AND and CMP zfilter in the packet matched with all outgoing Link IDs Multicasting: zfilter contains more than one outgoing links Interfaces Link ID zfilter & = Yes/No zfilter

15 Example: zf creation and forwarding Topology: zfilter formation IF 1-2 IF S OR Node 1: Match and forward IF 1-2: Topic ID DATA zfilter: & = Source IF S-1 Interface Link ID IF S IF 1-3 IF 1-1 Node 1 IF 1-2 Interface Link ID IF IF IF

16 Using Link Identity Tags (LIT) Make results better 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 Host 1: Iface out Link ID LIT 1 LIT 2 LIT n Host 2: Iface out Link ID LIT 1 LIT 2 LIT n Candidate zfilter zfilter 1 zfilter 2 zfilter n

17 Using Link Identity Tags (LIT) Interfaces LIT1 & = LIT2 d? & = LITn & = d BF Yes/No d BF

18 Forwarding efficiency Simulations with Rocketfuel SNDlib Forwarding efficiency with 20 subscribers ~80%

19 Forwarding efficiency Simulations with Rocketfuel SNDlib Forwarding efficiency with 20 subscribers ~80% LIT Optimized: 88% n

20 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 C D A B E F Virtual B->C->D->E

21 zfilter collection During packet traversal, the reverse zf can be easily generated Add a field in the packet for collected zfilter 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 IF 1-1 Node 1 IF 1-2 IF 2-1 Node 2 IF 2-2 DATA c-zf zf c-zf = c-zf OR LID1-1 Interface Link ID IF IF Matching for outgoing Interface Link ID IF IF

22 Security features - zformation

23 Forwarding security Goal: to ensure (probabilistically) that hosts cannot send un-authorized traffic zfilter weaknesses zfilter replay attacks Computational attack correlate zfilters to learn link IDs Traffic injection attack Solution (z-formation): Compute LIT in line speed and bind it to path: in-coming and out-going port time: periodically changed key flow: flow identifier (e.g. IP 5-tuple / content id)

24 Secure case: z-formation aka Secure in-packet BFs IN port # OUT port # Flow ID Z K(t) 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 d BF LIT(d) & = yes/no Flow ID from the packet, e.g. Information ID IP addresses & ports d from the packet

25 Security properties zfilter works both as a forwarding ID and a capability To send, a host needs to know or guess a valid zfilter Bound to the outgoing ports along the path Traffic injection possible Hard to construct one without knowing LITs along the path Correlation attacks possible Zformation Bound 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

26 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 Attack success probability max = 0.45 max = 0.50 max = 0.55 Pr = Attack path length (h) Number of attempts x ( max = 0.5)

27 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

28 zfilter implementation We had a novel forwarding mechanism Does it work? With simulations and prototyping we can verify We needed a platform that is powerful has fast interfaces supports implementing own functions is not too complex to learn and implement Decision NetFPGA seemed to meet our expectations zfilter forwarding node implementation FreeBSD was selected as the end-host implementation platform Also forwarding implementation

29 NetFPGA

30 Netfpga card general A low-cost platform suitable for research and teaching of networking hardware and router design Processing load moved from the CPU to the card Host CPU has access to the NetFPGA via registers Allows building of high-speed, hardware-accelerated networking system prototypes Uses Verilog and cross compilation environment NetFPGA project run at Stanford University Small group of people + large number of developers around the world

31 Netfpga

32 Netfpga reference implementation SCONE User level IPv4 router ARP, ICMP, PW-OSPF Telnet, web interfaces CLI: Command Line Interpreter Conf. routing table NetFPGA board HCORR; the hw part of the implementation

33 Hardware modules Reference pipeline 4 x 1Gb interfaces User data path 64-bits wide, running 125 MHz Max peak: 8Gbps RxQ Creates a module header Input Arbiter Retrieves packets from input interfaces

34 Hardware modules Reference pipeline Output Port Lookup Decision of the output port E.g. FIB on an IPv4 router Write destination port(s) to the module header Output Queues Use module header for putting the packet to the right queue(s) MAC: physical interfaces CPU: Interface to upper layer processing

35 verilog HDL - Hardware Description Language Phil Moore Similarities to programming languages Concurrency aspects: Modula, Simula Syntax: C Allows quick creation and debugging of large systems Modular design root & sub-modules Writing code Operations executed concurrently; think in clock cycles Not a sequentially processed programming language Everything can be simulated Synthesis Automatic translation of HDL into netlist of digital cells

36 Verilog Simulate in Linux Ubuntu has simulation tools Icarus Verilog Simulator Contains tools for compiling and simulating

37 zfilter implementation on a netfpga

38 Implementation - overview NS3 simulator FreeBSD 7.x: End-host and forwarding NetFPGA: Forwarding Open source: Publisher - FreeBSD Subscriber - FreeBSD Subscriber - FreeBSD NetFPGA NetFPGA

39 Features of the implementation Packet forwarding decision made when there is enough information available Packets arrive in 64-bit pieces zfilter 256 bits long Decision independently and simultaneously for each port in constant time Validity of zfilter checked simultaneously Number of 1-bits in the packet Wrong ethertype Zero TTL Variables used for routing can be modified from the user space Access specific memory addresses

40 Features of the implementation Maintains last packet forwarding information on the user space Monitoring and debugging Implemented features Basic zfilter based forwarding Link Identity Tag support Tested with 4 ports, each having 4 LITs Virtual Path support Same tests as with LITs Reverse path zfilter collection Done when the field exists MAC addresses still used Not mandatory, but no reason to remove at this point Own ethertype (ACDC) to distinguish from other packets

41 Implementation Based on the reference switch design Modifications only to the user data path input_arbiter output_port_lookup Input arbiter Parsers & LUTs output_port_selector output_queues output_queues

42 output_port_selector structure Register Interface Register access logic id_store ctrl bus data bus Status registers Header state parser Header counter Bit counter Ethertype Do zfiltering Combine results out_ports TTL

43 Functions by clock cycle Selections initialized to 1 set to 0 if comparison does not match bit counter: count bits set to one req. ID[0..63] req. ID[ ] req. ID [ ] req. ID [ ] wait for the packet, set selections to 1 get ethertype, remove inc. port from sel. set table index store TTL filter with ID [0..63] filter with ID [ ] filter with ID [ ] filter with ID [ ] Combine decisions from every table CLK cycles

44 Implementation zfilter: 500 lines of Verilog code Most of the code is in port_selector Forwarding decision simple clk) begin if (incoming_filter) // make forwarding decision selection[port]<= (selection[port])&((in_zfilter & id[port]) == id[port]); else if(out_selection_ready) out_selection<=selection; else selection<=1; end

45 overview of the New user datapath

46 Management software Configuring the id_store Read and configure LIT values Set d, the number of LITs per interface Set the length of the LITs Both real and virtual link information Testing with the software Send customizable data packets to the card, by defining outgoing interface delays between packets sizes of the packets TTL in the packet header (loop prevention) d for LIT selection the actual forwarding zfilter Collect information about the forwarding decisions made

47 Testing and measuring Early performance results Latency slightly smaller when compared to IP forwarding zf latency stays constant, independent of the network size Resource consumption 4 real and 4 virtual LITs per interface Most of the resource consumed by other components than zfiltering Path Avg. latency Std dev. Plain wire 94 µs 28 µs IP router 102 µs 44 µs zfilter 96 µs 28 µs Resource Used / Available 4-input LUTs / Slice Flip/Flops (FF) /

48 Experiences and Future work Easy to get started by using reference design Working proof-of-concept implementation Quite good initial performance results Future work Continue with the missing functionality Testing Performance measurements

49 Material available Implementations available at NetFPGA forwarding FreeBSD end-host implementation and forwarding Related publications available Jokela, Zahemszky, Esteve, Arianfar, Nikander, LIPSIN: Line-Speed Publish/Subscribe Inter-Networking, SIGCOMM '09 Keinänen, Jokela, Slavov, Implementing zfilter based forwarding node on a NetFPGA, NetFPGA Developers Workshop 2009 Esteve, Jokela, Nikander, Särelä, Ylitalo, Self-routing Denial-of- Service Resistant Capabilities using In-packet Bloom Filters, EC2ND 09

50