• These devices are managed and operated remotely Some malicious devices can also be connected to the network • Devices can be attacked easily because of the network topology Home Network Malicious Operation Malicious Devices Smart Devices Unintended Communication 2
architectures for ordinary users • Does not refer to the methods to apply them in a real network Network Access Control Methods • Proposing Software Defined Network(SDN) based access control • Does not consider user friendly management systems The gap between Access Control Architecture and Network Access Control exists 3
Capability based Authorization Architecture • Designed architecture relying on guidelines for access control in a home • Designed Automatic Authorization and Manual Authorization Proposal2: Network Access Control Method • Providing more fine-grained network access control (flow-based, payload-based and proxy-based control) • Designed twin device to apply our methods to existing devices 4
are two types • Outsourcing the management of networks • Configuring and managing networks by users Each method usually uses OpenFlow to control network • The granularity of control is restricted to “flow” 8
Feamster proposed spam detection by outsourcing the management of home network. • Osman proposed automatic network segmentation by analyzing home network and controlling with cloud-based system Outsourcing methods have Privacy and Availability problems • Service providers know what communications are done in a home • Service down means that home network is also unavailable 9  N. Feamster, “Outsourcing home network security,” in Proceedings of the 2010 ACM SIGCOMM Workshop on Home Networks, ACM, 2010, p. 37–42.  A. Osman, A. Wasicek, S. Kopsell, and T. Strufe, “Transparent microsegmentation in smart home iot networks,” in HotEdge ’20. USENIX, Jun. 2020, pp. 1–6.
• Mortier proposed OpenFlow based device management system. • Bakhshi proposed management using profiles. • Lear proposed Manufacturer Description Usage(MUD). A problem that not considering usability • Access control research results considering usability are not utilized 10  R. Mortier, T. Rodden, T. Lodge, D. McAuley, C. Rotsos, A. Moore, A. Koliousis, and J. Sventek, “Control and understanding: Owning your home network,” in COMSNETS 2012, pp. 1–10.  T. Bakhshi and B. Ghita, “User-centric traffic optimization in residential software defined networks,” in ICT 2016, pp. 1–6.  Lear, R. Droms, and D. Romascanu, “Manufacturer Usage Description Specification,” RFC 8520, Mar. 2019.
Model • Relying on guidelines for access control in home • Authorization per communication Every communication has a corresponding Capability 11 Capability Provider Smart Device A Smart Device B Allowed to communicate with device A! Cap(GetTEMP) Requesting Cap(GetTEMP) Capability: Get Temperature Protocol: UDP Port: 8000 Cap(GetTEMP) Issuing Capability
models • Capability is bound to each operation • Simply issuing a capability if a user authorizes operation • An entity allows the operation if the corresponding capability is presented 12 Entity 2 Operation A Operation B Cap(Operation A) Allow Operation A because of having Cap(Operation A) Deny Operation B because of not having Cap(Operation B) Entity 1 Issue Cap(Operation A) Allow Operation A
control systems aimed at home users 1. Allow fine-grained control 2. Plan for lending devices 3. Include reactive policy creation 4. Include logs 5. Reduce or eliminate up-front complexity 6. Support iterative policy specification 13  M. L. Mazurek, J. P. Arsenault, J. Bresee, N. Gupta, I. Ion, C. Johns, D. Lee, Y. Liang, J. Olsen, B. Salmon, R. Shay, K. Vaniea, L. Bauer, L. F. Cranor, G. R. Ganger, and M. K. Reiter, Access Control for Home Data Sharing: Attitudes, Needs and Practices. ACM, 2010, p. 645–654.
policy is embedded in capability Authorization policy is designed for cooperation in the same vendor • Device ID or Vendor ID are used in condition by default • Expanding policy is a future task 15 Capability Provider Vendor α’s Smart Device B Allowed to communicate with device A! Cap(GetTEMP) 2.Requesting Cap(GetTEMP) Capability: Get Temperature Protocol: UDP Port: 8000 Condition: Vendor Allowed Vendor: Vender α Cap(GetTEMP) Smart Device A 4. Issuing Capability 1.Delegating Cap(GetTEMP) 3. Checking and authorizing automatically
a user Capabilities are delegated to a user and a user authorize it. 16 Vendor β’s Smart Device B Authorize! Cap(GetTEMP) 2.Requesting Cap(GetTEMP) Capability: Get Temperature Protocol: UDP Port: 8000 Condition: Vendor Allowed Vendor: Vender α Cap(GetTEMP) Smart Device A Cap(GetTEMP) Capability Provider 4.Issuing Capability 1.Delegating Cap(GetTEMP) 3.Delegating Cap(GetTEMP)
more suitable than policy based one in a home network 17 Requirements Policy based Capability based (1) Fine-grained control ✕(difficult for small number and many kinds) ✔(Control per cap) (2) Lending device ✕ ✕ (3) Reactive policy creation (Out of consideration) ✔ (4) Logs ✔ ✔ (5) Reduce complexity ✕(Describing policy) ✔(only issuing) (6) Iterative policy specification ✕(Policy Management) ✔(Management per cap)
Policy Enforcement Point(PEP) • PEP checks the capability corresponding to communication is presented • Flow-based, Payload-based and Proxy-based control with OpenFlow and Twin devices 18 OpenFlow Twin Devices Cap(GetTEMP) Smart Device A Smart Device B Allow Communication between Smart Device A and B Communication to get temperature The other communications Policy Enforcement Point (PEP)
physical devices • Handling capabilities and providing payload-based and proxy-based access control • Network is separated from host using network namespace 20 OVS for access control Twin device (separated with network namespace) Payload-based and Proxy-based control Capability related processing To Capability Provider Packets are forwarded and checked
• Rough network separation • High throughput or low latency communication Flow-based access control works with OpenFlow 21 Physical Device A Physical Device B OpenFlow Switch or Wireless AP Controller Matching: - eth_src: 00:11:22:33:44:55 - eth_dst: FF:FF:FF:FF:FF:FF - ip_src: 192.168.1.2 - ip_dst: 192.168.1.255 - udp_dst: 8000 Action: OUTPUT(port:2) MAC Addr: 00:11:22:33:44:55 IPv4 Addr: 192.168.1.2/24 MAC Addr: 00:11:33:44:55:66 IPv4 Addr: 192.168.1.3/24
UDP packets • Some protocols use a UDP packet to search network and discover devices Payload-based access control uses • OpenFlow to forward packets to twin device • A twin device to inspect packet payload 22 Physical Device A Physical Device B OpenFlow Switch or Wireless AP PEP Twin Device B Twin Device A OVS Forwarding packets Inspect and forward or drop packets Condition: - payload == 0x14 && payload == 0xA4
stream messages • HTTP cannot be controlled with previous 2 methods. • Other protocols using TCP streams are also target. Proxy-based access control is based on a Transparent Proxy • Achieved by rewriting packets’ IP address with OVS 23 Physical Device A Physical Device B OpenFlow Switch or Wireless AP PEP Twin Device B TCP Proxy forwards or discards messages Condition: - Message Format: HTTP - Method: GET - Request URI : device/status TCP Proxy simply calling recv(2) and send(2) OVS Rewriting packets' header
AP • The firmware of Aruba AP11 is rewritten to OpenWrt to support OpenFlow In performance evaluation, we measured • Throughput with iperf3 • RTT(round trip time) with ping 25 PEP CP Smart Device A (Raspberry Pi) Smart Device B (Raspberry Pi) OpenFlow Wireless AP Linux Host (ThinkPad X260)
launch applications like Netflix in a smart TV from a smartphone in our hand DIAL protocol consists of two protocols • SSDP(Simple Service Discovery Protocol): for discovering devices • DIAL REST Service: for controlling devices via HTTP REST API 27
to each operation like Cap(NetflixStart) • Separating network roughly with flow-based access control • Controlling SSDP with payload-based access control • SSDP sends and receives UDP packet for device discovery • Controlling DIAL REST Service with proxy-based access control • REST API is served over HTTP We confirmed our proposed methods can control DIAL protocol • Methods using only flow-based control cannot provide such fine-grained access control • Payload-based and proxy-based methods enable access control. 28
than configuring policy! 31 Capability Provider Device B Device A PEP Twin Device B Twin Device A Twin Device B Twin Device A Capabilities Configuring OpenFlow switch OpenFlow switch Configuring twin devices
on guidelines for access control in home • Designed Automatic Authorization and Manual Authorization Proposal2: Network Access Control Method • Achieved more fine-grained control with flow-based, payload-based and proxy-based control • Designed twin device to apply our proposals to existing devices Experiments: Performance Evaluation and PoC in a DIAL protocol 33