1. MITIGATING LAYER 2 ATTACKS: RE-THINKING THE DIVISION OF LABOR M.Sc Final Project Nir Solomon Supervised by: Prof. Anat Bremler-Barr December 2015 | IDC Herzliya

2. General Idea in One Slide  While OpenFlow’s whole-view enables to gather network statistics to prevent attacks, it is also susceptible to some  Specifically: ARP Poisoning and Controller DDoS  We will show how these attacks are executed  Also –the Controller cannot support the load of handling all the forwarding decisions by itself  Our solution – called Reactive ARP Query, helps mitigate these attacks  By shifting Control-plane responsibilities back to the switch! SDN Switch Controller

3. Outline  OpenFlow – Intro  Legacy Network Layer 2 Attacks  Our Contribution  Related and Previous Work  SDN Layer 2 Attacks  Proposed Solution  Evaluation  Conclusions

4. OpenFlow - Introduction  Provides a scalable way to manage SDN networks  Control-Plane and Data-Plane  A centralized Controller  “Whole” view of the network  The ability to gather information and statistics from every network component O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

5. OpenFlow – Flow Tables  Every flow that has been installed by the Controller, is added to a “flow table” residing on the Switch ActionDST MACSRC MACRule Output to port 100:20:B9:CC:2D:A8AA:BB:CC:DD:EE:EERule 1 Output to Port 200:6F:25:1B:99:0C00:11:22:33:44:BE:EFRule 2 Send to Controller* (Don’t Care) Rule 3 O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

6. OpenFlow – Learning Switch  An application running on the Controller  Reactively installs flows on the switch for every packet that don’t have a matching flow and arrives an the Controller  This event is called a packet-in  The next time that a packet is received by the switch, it will be handled and forwarded automatically O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

7. Reactive  Packet not matching any flow triggers controller to insert flow entries  Efficient use of flow table  Every flow incurs small additional flow setup time  If control connection lost, switch has limited utility Proactive  Controller pre-populates flow table in switch  Must know the network topology ahead of time  Zero additional flow setup time  Essentially requires aggregated (wildcard) rules  Hard to install new flows after the network starts operating – problematic in BYOD networks OpenFlow – Reactive & Proactive O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

8. The ARP Protocol  ARP Request: –Argon broadcasts an ARP request to all stations on the network: “What is the hardware address of 128.143.137.1?” O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

9. The ARP Protocol  ARP Reply: –Router 137 responds with an ARP Reply which contains the hardware address O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

10. The ARP Protocol - Cache  Hosts maintain a table (ARP Cache) of current entries for each NIC installed  The entries expire after some time (implementation dependant – e.g. Windows XP - 2 mins, RedHat - 60 secs).  For example, an ARP cache in Windows (“arp -a” ): O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

11. Gratuitous ARP - an ARP request/reply that is not normally needed according to the RFC but could be used in some cases  Request: the packet has the source and destination IP both set to the IP of the machine issuing the packet and the destination MAC is the broadcast address  Reply: is a reply to which no request has been made Useful for:  Detecting IP conflicts  Push update to other machines’ ARP tables (e.g. when host changes its IP address)  Inform switches of the hosts’ address on a given switch port O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS The ARP Protocol – Gratuitous ARP

12. Layer 2 Attacks – ARP Poisoning  A forged ARP Request or Reply can be used to update the ARP cache of a remote system with a forged entry O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Switch Alice MAC: 00:00:00:00:00:01 IP: 192.168.1.1 Bob MAC: 00:00:00:00:00:02 IP: 192.168.1.2 Eve MAC: 00:00:00:00:00:03 IP: 192.168.1.3 192.168.1.2 is at 00:00:00:00:00:03 192.168.1.1 is at 00:00:00:00:00:03 To: 00:00:00:00:00:03 192.168.1.2

13. Layer 2 Attacks - DDoS  The attempt to make a machine or service unavailable to its legitimate users, by consuming its resources by a large group of attackers  A DDoS scenario may quickly worsen, such as when sending a packet to the victim will cause him to send a reflected packet to another host  In many cases, the best solution to contain the damage is to use Rate Limiting  We will show that it is possible to create a Layer 2 DDoS on the OpenFlow Controller, while using only ARP packets O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

14. Our Contribution In summary, our work makes the following contributions:  Overview of an ARP Poisoning attack and its execution in an OpenFlow network  Presentation of a new attack vector on OpenFlow - ARP level Distributed Denial of Service (DDoS) attack on the OpenFlow Controller  Extension of the current implementation of OpenFlow to include new mechanisms to mitigate Layer 2 attacks, and an evaluation O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

15. Related & Previous Work O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS  Legacy ARP Poisoning Mitigation:  [Nam et al, 2010]  OpenFlow Vulnerability Assessments – including DDoS:  [Yan et al, 2015], [Kloti et al, 2013], [Benton et al, 2013]  Using specially-crafted packets to attack OpenFlow networks:  [Shin and Gu, 2013]  Shifting responsibilities from the Controller to the Switch:  [Shin et al, 2013], [Curtis et al, 2011]  Using the Whole-View of SDN to mitigate network attacks:  [Braga et al, 2013], [Phaal et al, 2013], [Porras et al, 2013], [Porras et al, 2012]

16. SDN Attacks - ARP Poisoning O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS SDN Switch Alice MAC: 00:00:00:00:00:01 IP: 192.168.1.1 Bob MAC: 00:00:00:00:00:02 IP: 192.168.1.2 Eve MAC: 00:00:00:00:00:03 IP: 192.168.1.3 192.168.1.2 is at 00:00:00:00:00:03 192.168.1.1 is at 00:00:00:00:00:03 To: 00:00:00:00:00:03 192.168.1.2 ActionIN PORTSRC MAC ActionDST MAC Table 0 Table 1 GOTO Table 1300:00:00:00:00:03 OUTPUT to 300:00:00:00:00:03 GOTO Table 1100:00:00:00:00:01 GOTO Table 1200:00:00:00:00:02 OUTPUT to 100:00:00:00:00:01 OUTPUT to 200:00:00:00:00:02

17. SDN Attacks – Controller DDoS  We would like to overload the Controller with multiple packet-in events  An attacker can spoof a packet as he likes  Let us create a specially crafted packet that will cause a packet-in  This attack is unique to OpenFlow and inherent in its design O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

18. SDN Attacks – Controller DDoS Crafted Packet No Flow available  Send to Controller Packet-in O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

19. SDN Attacks – Controller DDoS  Controller: running on a MacBook Pro with 16GB of RAM and Core i7 CPU  Attacker: simulated with Cbench on an Ubuntu machine with Core i5 CPU and 4GB of RAM  Reaching a certain threshold of about 1.3 Mpps (million packet-ins per second), the number of responses does not increase correspondingly O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

20. Solution - Desired Properties  A “normal” Reactive learning switch enables both ARP Poisoning and a DDoS attack  We would like to define a solution with the following properties:  Little load on the Controller  Lesser number of flows installs on the Switch  A Reactive solution  We can use multiple or distributed Controllers to mitigate DDoS  This is an orthogonal solution  We will compare our proposed solution to the Reactive approach, and the tradeoffs of using it O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

21. Solution - Shifting Control-Plane Responsibilities  Usually, separation between the control plane and the data plane  Creates a load on the Controller  Shifting responsibilities from Controller  Switch  Allowing the switch to hold the IP to-MAC mappings of the hosts connected to it  Similar to all the mappings usually held by the Controller  Shifting control plane responsibilities has been suggested:  AvantGuard [Shin et al, 2013]  DevoFlow [Curtis et al, 2011] O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

22. Solution – General Idea  In both Layer 2 attacks, spoofed ARP packets are used  We aim to retain:  IP-to-MAC mappings and MAC-to-Physical port mappings  Of each host connected to the switch  Saved in the switch, in the form of OpenFlow flows  When a new host connects to the network, we want to “authenticate” it  No matching flow for a packet sent from the new host  We will send a “Reactive ARP Packet”  If and only if the host is validated, we will send a packet-in to the Controller  Else: drop the packet O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

23. Solution – Attacker Types  When discussing the use of spoofed ARP packets, there are two kinds of attackers:  Naive Attacker: will not reply to an ARP request for the (MAC, IP) he spoofs  Sophisticated Attacker: will reply to an ARP request for the (MAC, IP) he spoofs O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

24. Solution – Possible Scenarios When sending the Reactive ARP Query, there are three possible scenarios:  Two ARP replies (one with expected MAC, one with other MAC)  Invalid ARP reply (a packet is returned with a different MAC address than expected/No reply)  Valid ARP reply (matching IP and MAC) O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

25. Solution – Scenario 1 Scenario 1: Two ARP replies (one with expected MAC, one with other MAC) This is a sophisticated attacker! O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS SDN Switch Eve MAC: 00:00:00:00:00:03 IP: 192.168.1.3 WHO HAS 192.168.1.154? Spoofed SRC MAC:00:00:00:00:00:99 Spoofed SRC IP: 192.168.1.1 Controller Alice MAC: 00:00:00:00:00:01 IP: 192.168.1.1 ActionSRC PORTSRC IPSRC MAC GOTO Table 11192.168.1.100:00:00:00:00:01 WHO HAS 192.168.1.1? 192.168.1.1 is at 00:00:00:00:00:01 192.168.1.1 is at 00:00:00:00:00:99 DROP! (no packet-in)

26. Solution – Scenario 2 Scenario 2: Invalid ARP reply (a packet is returned with a different MAC address than expected/No reply) O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS SDN Switch Eve MAC: 00:00:00:00:00:03 IP: 192.168.1.3 WHO HAS 192.168.1.154? Spoofed SRC MAC:00:00:00:00:00:99 Spoofed SRC IP: 192.168.1.1 Alice MAC: 00:00:00:00:00:01 IP: 192.168.1.1 ActionSRC PORTSRC IPSRC MAC GOTO Table 11192.168.1.100:00:00:00:00:01 WHO HAS 192.168.1.1? 192.168.1.1 is at 00:00:00:00:00:01 DROP! (no packet-in) Controller

27. Solution – Scenario 3 Scenario 3: Valid ARP reply O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS SDN Switch Eve MAC: 00:00:00:00:00:03 IP: 192.168.1.3 WHO HAS 192.168.1.2? Spoofed SRC MAC:00:00:00:00:00:99 Spoofed SRC IP: 192.168.1.99 ActionSRC PORTSRC IPSRC MAC GOTO Table 11192.168.1.100:00:00:00:00:01 WHO HAS 192.168.1.99? Host (or attacker) is validated 192.168.1.99 is at 00:00:00:00:00:99 Alice MAC: 00:00:00:00:00:01 IP: 192.168.1.1 Packet-in Packet-out+ Install Flow GOTO Table 13192.168.1.9900:00:00:00:00:99

28. Solution – What About the Last Scenario?  A sophisticated attacker may still be validated – he can still create packet-ins!  We can use a Rate Limiting mechanism  Rate limit only the table misses  Only the physical port of the sender  Also used against DNS DDoS Amplification attacks O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

29. Solution – Rate Limiting  “With regard to denial-of-service vulnerabilities, controller vendors need to emphasize the importance of rate-limiting.”  “Even for an application as simple as this one (Learning Switch) protecting it requires implementing MAC spoofing protection through port counters (with timers if network flexibility is required), rate limiters for traffic to unknown hosts, and switch rules for multicast.”  “Networks that rely heavily on PacketIn messages (i.e. reactive designs) can be exposed to denial-of-service attacks against the switches and controller(s) without complex rate-limiting logic in the controller.” O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS OpenFlow Vulnerability Assessment, [Benton et al, SIGCOMM 2013]

30. Solution – Rate Limiting (Continued)  Work is being done to gather network statistics in OpenFlow  Flow Collector - Percentage of Pair-flows (PPf) – [Braga et al, 2013]  “Pair-Flow”:  The source IP of flow 1 must be equal to the destination IP of flow 2  The destination IP of flow 1 must be equal to the source IP of flow 2  Both flows must have the same communication protocol  DDoS increases the number of “single-flows”  A switch that has a host suspected as a sophisticated attacker, may use these statistics to decide if the physical port has a large number of single-flows, and limit it accordingly  Out of the scope of this work O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

31. Solution – Assumptions  We assume a steady state when the network starts operating  If an attacker binds the victim’s IP address to its MAC address before the victim connects, the victim’s packets will be dropped  Can be prevented:  By using our solution as soon as the network starts operating  Or by installing proactive rules for all known safe hosts ahead O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

32. Solution – The Division of Labor  There is a fine line between the Control Plane and the Data Plane  Only some suggested that this line should be crossed  ״ When thinking of the default component used to mitigate network attacks in an SDN network, we think of the Controller ״ - [Braga et al, 2013]  We conclude that the Controller, by itself, cannot hold these responsibilities, as the load may cause it to stop function correctly  Instead, our approach takes the a different direction; we shift these responsibilities from the “default” component, the Controller (control plane) into the switch (data plane) O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

33. Evaluation – ARP Poisoning O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS SDN Switch Alice MAC: 00:00:00:00:00:01 IP: 192.168.1.1 Bob MAC: 00:00:00:00:00:02 IP: 192.168.1.2 Eve MAC: 00:00:00:00:00:03 IP: 192.168.1.3 192.168.1.2 is at 00:00:00:00:00:03 ActionIN PORT SRC IPSRC MAC Table 0 – Steady State GOTO Table 11192.168.1.100:00:00:00:00:01 GOTO Table 12192.168.1.200:00:00:00:00:02 WHO HAS 192.168.1.2? 192.168.1.2 is at 00:00:00:00:00:03 192.168.1.2 is at 00:00:00:00:00:02 DROP! (also: no packet-in)

34. Evaluation – DDoS Naive Attacker - Packet-ins  Using a normal OpenFlow Switch, each spoofed packet requires a packet-in to be received by the Controller  Using the Reactive ARP Query Switch, no packet-ins are received at the Controller at all O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

35. Evaluation – DDoS Naive Attacker - Flows Installed  Using a normal OpenFlow Switch, two flows will be installed for each packet-in - one matches on the source, and one on the destination  In our solution, we drop the attacking packet, without installing any flows, and without informing the Controller O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

36. Evaluation – DDoS Sophisticated Attacker - Packet-ins  Using a normal OpenFlow Switch, each spoofed packet requires a packet-in to be generated by the switch and received by the Controller  Using the Reactive ARP Query Switch, the rate of the packet-ins are limited (in our case, to 100 packets per second, chosen arbitrarily)  If the Rate-Limiting rate is N pps, then we can assure that the maximum packet-in rate at the Controller will be N pps as well O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

37. Evaluation – DDoS Sophisticated Attacker - Flows Installed  Using a normal OpenFlow Switch, two flows will be installed for each packet- in - one matches on the source, and one on the destination  In our solution, we rate-limit the incoming packet-ins, so the rate of the creation of new flows depends on the rate limitation O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

38. Evaluation – Network Overload The three possible scenarios are:  Two ARP replies (one with expected MAC, one with other MAC).  Invalid ARP reply (a packet is returned with a different MAC address than expected/No reply).  Valid ARP reply (matching IP and MAC). Sophisticated Attacker. The first packet sent by him will be intercepted by the switch. A single Reactive ARP packet will be issued for the attacker’s packet to be dropped. The attacker is naive and a single Reactive ARP packet is used for the packet to be dropped. Might be the attacker’s packet or a valid host the connected to the network. Let us assume the worst case scenario - that this host is an attacker. We will send an ARP validation, and he will be validated. No more packets from him with his SRC MAC will be validated as a flow is being installed by the Controller. Thus the network overhead here is only a single packet O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

39. Conclusions We presented the execution of Layer 2 attacks in OpenFlow network: ARP Poisoning; and a Layer 2 DDoS on the Controller, which is an inherent vulnerability in OpenFlow networks. We have proposed an extension to OpenFlow – Reactive ARP Query. While our solution has only a minor network overhead, both attacks can be mitigated successfully. This is a major step in changing our approach by shifting the control plane responsibilities back to the switch. O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

40. Future Work  We hope to allow the creation of a “smart” Rate-Limiting algorithm, by gathering flow metrics from the whole network  Rate-Limit the physical port according to the flow metrics gathered  We hope to also implement the Reactive ARP Query extension on a physical switch. This implementation will allow the evaluation of its performance while running as a totally independent data plane component O PEN F LOW – I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS

41. Questions? Thanks!