Pith. sign in

REVIEW 4 major objections 5 minor 108 references

Programmable In-Network Security for Context-aware BYOD Policies

T0 review · 4 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Poise claims that context-aware BYOD security can be enforced entirely inside programmable switch hardware, eliminating the remote controller from the decision path and surviving floods that saturate OpenFlow-based SDN defenses.

desk verdict Solid hardware-backed systems paper showing context-aware BYOD enforcement can live in the data plane; the replay/binding gap is real but disclosed, and the missing switch-CPU numbers are the main revision item. read the letter →

arxiv 1908.01405 v1 pith:YJTF3WNK submitted 2019-08-04 cs.NI cs.CR

Qiao Kang , Lei Xue , Adam Morrison , Yuxin Tang , Ang Chen , Xiapu Luo This is my paper · ORCID
classification cs.NIcs.CR
keywords context-awaresecurityBYODprogrammabledataplanesP4in-networksoftware-definednetworkingcontrolplanesaturationaccess
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Poise claims that context-aware security for BYOD networks can be enforced entirely inside programmable switch hardware, removing the central controller from the packet-processing path. Mobile devices append compact context headers containing signals such as GPS location, time of day, library version, foreground app, and admin status to occasional context packets; the switch evaluates those headers and makes the access-control decision at 100 Gbps line rate. A declarative policy language, adapted from NetCore, compiles into P4 instantiations of a switch primitive, so operators write concise policies instead of low-level switch programs. The paper reports that security postures change in under 500 nanoseconds, about four to seven orders of magnitude faster than controller round-trips, and that legitimate connections keep succeeding while a one-million-connections-per-second flood collapses an OpenFlow-based baseline. If correct, this replaces a security model that must wait on remote software with one that is fast, programmable, and resistant to control-plane denial of service.

What carries the argument

The load-bearing mechanism is the in-network security primitive, a hardware pipeline instantiated in P4 from four components: custom context headers that the switch parser extracts from client traffic; match/action tables that evaluate policy predicates, including arithmetic over GPS coordinates and membership tests against constant lists; stateful registers implementing monitors such as count(pred), which let a packet's fate depend on network-wide state like whether an admin is online; and a key/value store that approximates per-flow state without per-flow memory. That store combines a FullConn match/action table, a small CRC-indexed Cache that buffers decisions for new connections while the control plane installs entries, and a Bloom filter that blacklists recently violating source addresses so they are denied early. The cache-and-bloom-filter design is what allows the switch to keep making correct decisions during the control-plane insertion window, and the compiler translates NetCore-style policies into instantiations of this primitive using table deduplication, table merging, and packet recirculation when policies exceed the available hardware stages.

What would settle it

Root a device running PoiseDroid, forge a context packet that claims a safe location, an online admin, or a patched library while the device's true state is the opposite, and observe whether the switch grants access; the paper's trust model predicts the switch enforces the forged decision, and any detection-and-drop behavior would contradict the model. A second test targets the cache: an attacker who learns the CRC hash could flood context packets to evict a victim's cache entry, and the victim's data packets should then suffer recirculation-induced latency or spurious drops if the heuristic countermeasure fails.

Watch

Extended reading notes

Core claim

The central claim is that the end-node problem of BYOD security can be solved by a switch primitive that performs context-aware access control in hardware on the data plane. Poise defines a property called subflow-level security: a context packet, which carries the device's current signals, refreshes the stored decision for a flow, and all subsequent data packets of that flow are governed by that decision until the next context packet arrives. The context-packet frequency is tunable, so the operator trades security granularity against overhead, from per-flow to near-per-packet. Because decisions are made by match/action tables and stateful registers rather than by a software controller, the paper argues that the resulting defenses are efficient, programmable, highly agile, and resilient to control plane saturation attacks. The prototype evaluation on a Tofino switch reports full per-port line rate, roughly 88 to 100 nanoseconds of added latency, constant connection success during a one-million-connections-per-second saturation attack, and security-posture-change times below 500 nanoseconds.

Load-bearing premise

Poise's trust model, stated in Section 2.2, assumes the Android kernel and firmware, including the pre-installed PoiseDroid module, are trusted so that malicious apps cannot obtain root privileges or forge the context headers that drive every switch decision; if an attacker compromises that kernel code, each downstream allow-or-deny decision can be trivially bypassed.

Editorial extensions

If this is right

  • Enterprise access control can react to a device leaving an authorized area, an app moving to the background, or an admin going offline within hundreds of nanoseconds, shrinking the exploitable window in which a stale allow decision still stands.
  • Connection floods no longer translate into security failure: new connections are cached at line rate while the control plane installs entries asynchronously, so legitimate clients keep connecting even under a one-million-connections-per-second attack.
  • Operators can change policy as a recomputation: the compiler turns a few declarative lines into hardware programs in under one second, replacing hand-written P4 and hardware upgrades.
  • Policies that depend on network-wide state, such as denying access to sales records unless the sales manager is online, become expressible and enforceable in hardware, which client-only or stateless in-network designs cannot do.
  • The measured resource headroom of about 43 percent SRAM, under 1.1 percent TCAM, and under 7 percent VLIW utilization indicates the security primitive can coexist with other switch functionality on the same chip.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • My inference: the same subflow-level pattern could carry dynamic attributes beyond BYOD context, such as IoT device state, threat-intelligence score feeds, or per-tenant quota usage, since any attribute that fits in a periodically refreshed header can ride the same primitive.
  • My inference: the agility advantage only matters if the context signals are authentic, so the natural stress test is a rooted or kernel-compromised device forging a context header; the paper's own trust model concedes such a device would defeat every switch-side check.
  • My inference: the cache-eviction defense is heuristic, since collisions between different source IPs are only opportunistically resolved, so an attacker who can probe the CRC hash behavior might still single out a victim's cache entry and force repeated recirculations that degrade that victim's throughput.
  • My inference: if programmable switches become standard enterprise edge equipment, the broader architectural consequence is that security enforcement migrates from controller software and middleboxes into the forwarding fabric itself, which would simplify BYOD and IoT architectures but concentrate new trust in the switch.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. Poise proposes a new paradigm for context-aware BYOD security in which access-control decisions are enforced entirely in programmable switch hardware rather than by a remote SDN controller. The paper presents a high-level policy language with a compiler that generates P4 programs for a stateful in-network security primitive; a client-side kernel module (PoiseDroid) that collects and embeds context signals; and an orchestration controller. The prototype is evaluated on a Wedge 100BF Tofino switch with measurements showing 88–100 ns added packet-processing latency, full 100 Gbps per-port throughput, sub-500 ns agility in changing security posture, and stable connection success during a 1M-connection-per-second attack that collapses an OpenFlow/OpenvSwitch baseline. The central claim is that programmable in-network enforcement avoids the control-plane bottleneck and dramatically improves defense agility compared to centralized SDN defenses.

Significance. If the security-binding and comparison-fairness concerns below are addressed, this is a strong systems contribution. The paper ships a real hardware prototype, reports direct measurements on a Tofino switch, and makes concrete, falsifiable performance claims (added latency, line-rate throughput, saturation resilience). The compiler-based mapping from a declarative policy language to P4 is a useful artifact in its own right, and the identified design space—subflow-level security with tunable context frequency—is well motivated. The work also has no fitted parameters or circular derivations, and the comparison against a real OpenFlow controller gives the performance claims evidentiary weight. The main weakness is that the security argument around context-packet binding and replay is incomplete, and the SDN comparison does not impose the same context-packet workload on the baseline.

major comments (4)
  1. [§5.1, Fig. 5] The FullConn key is only [sip, sport, proto], so the switch cannot bind a context decision to a specific connection instance. A client can reuse the same source port for a new connection (or maintain simultaneous connections that share the 3-tuple but differ in destination), and the decision from the previous connection's context packet will be applied to the new connection. Section 5.1 acknowledges this inaccuracy but mitigates only the deny-to-allow case by blacklisting the source IP. A stale allow decision can persist and grant access after the device's context has changed to deny, and a stale deny can cause availability loss. The paper needs either a stronger binding mechanism (e.g., including a connection/flow identifier and checking freshness at the switch) or an explicit security analysis of the residual stale-decision window.
  2. [§2.2, §6] The trust model says malicious apps cannot compromise the kernel or obtain root, but it does not specify what a non-root malicious app can do to the context-packet stream. PoiseDroid generates context packets in the kernel network submodule, yet the paper does not analyze whether a malicious app can trigger, delay, reorder, or suppress context packets for its own sockets, or whether such actions can refresh an allow decision or evict cache entries for other connections. WPA3/MACsec protect the context packet on the link, but they do not protect against an adversary that controls an unprivileged app on the same device. The paper should either bound the app's influence on context-packet generation or add a concrete mechanism (e.g., per-connection nonces and switch-side freshness checks) before the subflow-level security claim is justified.
  3. [§7.7, Fig. 11] The control-plane saturation comparison does not impose the same context-packet workload on the SDN baseline as on Poise. In the Poise design, each new socket and each periodic context refresh generates a context packet that must be processed; in the OpenFlow baseline, those same client context updates would arrive at the controller and trigger FlowMod processing. The reported attack only measures new-connection PacketIn load, not the additional context-change load that a real Poise deployment would generate. Without measuring the baseline under the same per-connection and per-context-refresh load, the claim that Poise is 'resilient to control plane saturation attacks' relative to SDN is not fully established. Please add the context-change workload to the baseline and report both new-connection and context-change success rates.
  4. [§5.2] The cache-eviction attack defense relies on the attacker not knowing the CRC hash seed, but CRC-16 is not a keyed cryptographic hash and has only 2^16 possible outputs. An attacker who can observe hash behavior or brute-force the seed can predict which source-port values collide, undermining the claim that 'the attacker may not know the hash seed, therefore cannot predict who would be the victim.' The paper should either use a keyed/secret hash for cache indexing or provide a quantitative analysis of the residual DoS damage when the hash seed is known.
minor comments (5)
  1. [§3.1] The phrase 'and and deep packet inspection' contains a duplicated conjunction; please fix the typo.
  2. [§7.5] The word 'suppprt' in the sentence about the number of checks should be 'support'.
  3. [References [90]] The reference to Shin et al. appears as 'V ANTGUARD' in the text; the correct paper title is 'AVANT-GUARD: Scalable and Vigilant Switch Flow Management in Software-Defined Networks.'
  4. [§5.2] The stated cache size arithmetic is inconsistent: 2^16 entries with the described entry format yields approximately 0.5 MB, not the reported 0.38 MB. Please reconcile the entry-size accounting.
  5. [§7.2] The sentence 'four 25 Gbps Ethernet ports, which collectively can emulate eight forwarding decisions' is unclear; please specify how eight decisions follow from four ports.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: Poise is a self-contained systems construction with external measurements, and its only self-citation is non-load-bearing.

full rationale

No circularity found. Poise's central claim is a systems construction: a declarative policy language is compiled into P4 programs implementing a switch primitive (§4.3, Figure 4), and the evaluation (§7) directly measures the generated programs' latency, throughput, scalability, client overhead, and behavior under control-plane saturation attacks against an external Floodlight/OpenvSwitch SDN baseline (§7.7). No predicted quantity is obtained by fitting to the same data, and no design parameter is renamed as a result. The only self-citation is the HotCloud position paper [76], which the paper explicitly describes as closest related work that "neither has a full system implementation nor evaluation"; it is not used to justify any load-bearing inference. The trust model is inherited from external prior work [62, 98] and is explicitly stated as an assumption rather than derived. Subflow-level security is a stated design property implemented through the FullConn/Cache key-value store, not a theorem derived from its own definition. Accordingly, the derivation chain is self-contained and the paper earns a circularity score of 0.

Assumptions & free parameters 3 free parameters · 6 assumptions · 0 invented entities

No invented physical entities are introduced. The new hardware data structures (FullConn, Cache, Bloom filter) and the context header are engineered designs implemented and evaluated in the paper, not unexplained postulates requiring independent evidence.

free parameters (3)
  • Cache size = 2^16 entries
    Chosen to match the CRC-16 hash output, giving 0.38 MB memory usage in Section 5.2. It determines collision and eviction behavior and is a hand-chosen design parameter, not fitted to the target result.
  • Recirculation limit k = not specified
    Section 5.2 states packets are recirculated up to k times, where k is chosen to be larger than the expected control plane population time. The exact value is not reported, and it trades latency against the chance of dropping legitimate new flows.
  • Context packet frequency f = 1 packet per second
    Section 7.6 uses one context packet per second for the optimized client, yielding 1.3% CPU overhead and under 0.01% traffic overhead. The subflow-level granularity and overhead numbers depend on this tunable frequency.
assumptions (6)
  • domain assumption P4 programs that compile successfully are guaranteed to run at linespeed; programs exceeding hardware resources are rejected.
    Section 3.3 cites this property as the basis for linespeed programmability; the evaluation depends on the Tofino P4 compiler honoring this guarantee.
  • domain assumption Malicious apps cannot compromise the Android kernel or obtain root privileges; the kernel and firmware are trusted.
    Section 2.2 states this trust model. If violated, the PoiseDroid kernel module can be tampered with and context signals forged, evading all switch decisions.
  • domain assumption Context packets are protected from masquerading and replay by WPA3 and MACsec on the links they traverse.
    Section 2.2 states that context packet integrity and privacy follow the same protections as normal traffic and rely on WPA3 and MACsec; Poise itself adds no authenticity check on context headers.
  • standard math A Bloom filter never produces false negatives, only false positives.
    Section 5.2 uses this property to argue illegal connections are always rejected on a Bloom filter hit, with false positives only causing conservative drops.
  • domain assumption Enterprise networks can prevent source IP spoofing, so per-IP connection limits and blacklists are effective.
    Section 5.3 relies on spoofing prevention to make the total residency and cache eviction defenses sound.
  • domain assumption A context packet is generated when a new socket opens or a dormant socket reactivates, so it generally precedes data packets of a new flow.
    Section 6 describes this client behavior; if context packets are delayed or lost, new-flow data packets are dropped after the recirculation limit, which is conservative but can break legitimate connections.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Programmable In-Network Security for Context-aware BYOD Policies." pith.science (2026). https://pith.science/paper/YJTF3WNK

@misc{pith2026190801405,
  author       = {Pith},
  title        = {Pith review of: Programmable In-Network Security for Context-aware BYOD Policies},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YJTF3WNK}},
  note         = {Machine review of arXiv:1908.01405}
}
read the original abstract

Bring Your Own Device (BYOD) has become the new norm in enterprise networks, but BYOD security remains a top concern. Context-aware security, which enforces access control based on dynamic runtime context, holds much promise. Recent work has developed SDN solutions to collect device context for network-wide access control in a central controller. However, the central controller poses a bottleneck that can become an attack target, and processing context changes at remote software has low agility. We present a new paradigm, programmable in-network security (Poise), which is enabled by the emergence of programmable switches. At the heart of Poise is a novel switch primitive, which can be programmed to support a wide range of context-aware policies in hardware. Users of Poise specify concise policies, and Poise compiles them into different instantiations of the security primitive in P4. Compared to centralized SDN defenses, Poise is resilient to control plane saturation attacks, and it dramatically increases defense agility.

Figures

Figures reproduced from arXiv: 1908.01405 by the authors.

Figure 1
Figure 1. P4 switches are programmable in hardware. Packets [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Poise compiles a high-level policy into a) switch programs, and b) device configurations, and enforces the pol￾icy inside the network. These hardware features are programmable in P4 [19, 45]. Switch programs can be compiled and installed from the switch control plane ( [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. The language syntax for Poise policies. Context fields are represented as h. Expressions are represented as e, or v (constants). The ◦ operator indicates comparisons. could refer to the lists as part of the decision-making process, such as if match(!dev in adminlst) then fwd(mbox), which forwards traffic from non-admin devices to a middle￾box for traffic scrubbing. We note that the original NetCore does not support … view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: The Poise compiler processes the key language constructs and generates P4 implementations. The P4 snippets shown are simplified for clarity of presentation. For instance, in (b), the instantiation of the thresh register is not shown; in (d), the timestamp of a packet i…
Figure 5
Figure 5. Figure 5: The key/value store with example entries. [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 7
Figure 7. Figure 7: The architecture of the PoiseDroid client module. [PITH_FULL_IMAGE:figures/full_fig_p010_7.png]
Figure 8
Figure 8. Figure 8: The amount of processing latency of Poise is small. 0 50 100 Per-port P1 P2 P3 P4 P5 P6 P7 throughput (Gbps) Policy [PITH_FULL_IMAGE:figures/full_fig_p011_8.png]
Figure 9
Figure 9. Figure 9: Poise achieves full linespeed programmability. 7.4 In-network processing overhead Next, we turn to evaluate the overhead of Poise in terms of packet processing latency and switch throughput. Packet processing latency. Poise adds to the overhead of packet processing, si…
Figure 10
Figure 10. Figure 10: Poise can perform 1.2 million concurrent range checks for a single context, or 21k concurrent range checks for a maximum of 40 context types. Context packets with more than 5 context types need to be recirculated multiple times; Poise supports a maximum of 8 recircula…
Figure 11
Figure 11. Figure 11: Poise is resilient to control plane saturation attacks. Attack strength is measured by the number of new connec￾tions (or context changes for existing connections) per second. New connections trigger PacketIn and FlowMod events, and context changes trigger FlowMod eve…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

108 extracted references · 80 canonical work pages

  1. [1]

    http://www.lysesoft.com/products/ andftp/

    AndFTP. http://www.lysesoft.com/products/ andftp/

  2. [2]

    https://www.android.com/en terprise/employees/

    Android for Work. https://www.android.com/en terprise/employees/

  3. [3]

    https: //www.securewirelessworks.com/datashee ts/Access-Points/DS_AP220Series.pdf

    Aruba 220 series access points. https: //www.securewirelessworks.com/datashee ts/Access-Points/DS_AP220Series.pdf

  4. [4]

    https://www.barefootnetworks .com/technology/#tofino

    Barefoot Tofino. https://www.barefootnetworks .com/technology/#tofino

  5. [5]

    https://goo.gl/y m9ATg

    The benefits and risks of BYOD. https://goo.gl/y m9ATg

  6. [6]

    https://www.blackberry.com /us/en/solutions/enterprise-mobility-man agement-emm

    Blackberry EMM. https://www.blackberry.com /us/en/solutions/enterprise-mobility-man agement-emm

  7. [7]

    https://goo.gl /bn1rN4

    Bring your own risk with BYOD. https://goo.gl /bn1rN4

  8. [8]

    https://goo.gl/BTr Sm4

    BYOD: A global perspective. https://goo.gl/BTr Sm4

Show all 108 references
  1. [9]

    ht tps://goo.gl/phTav6

    BYOD: Mobile devices threats and vulnerabilities. ht tps://goo.gl/phTav6

  2. [10]

    https://www.cavium.com/xplia nt-ethernet-switch-product-family.html

    Cavium XPliant. https://www.cavium.com/xplia nt-ethernet-switch-product-family.html

  3. [11]

    https: //www.cisco.com/c/en/us/products/switc hes/nexus-3000-series-switches/models-co mparison.html#~tab-nexus3400

    Cisco nexus 3400 series switches. https: //www.cisco.com/c/en/us/products/switc hes/nexus-3000-series-switches/models-co mparison.html#~tab-nexus3400

  4. [12]

    https://goo.gl/D99C39

    End node. https://goo.gl/D99C39

  5. [13]

    https://goo

    How to solve the end node problem. https://goo. gl/9wWqJr

  6. [14]

    https://goo.gl/zafGxN

    IBM Mobile: BYOD. https://goo.gl/zafGxN

  7. [15]

    https://goo.gl/WBn3vP

    IBM opens up smartphone, tablet support for its work- ers. https://goo.gl/WBn3vP

  8. [16]

    https://1.ieee802

    IEEE 802.1ae: MAC security. https://1.ieee802. org/security/802-1ae/

  9. [17]

    https://www.intel.com/conten t/www/us/en/products/network-io/ethernet /switches.html

    Intel FlexPipe. https://www.intel.com/conten t/www/us/en/products/network-io/ethernet /switches.html

  10. [18]

    https://goo.gl/25SX7K

    Market reports. https://goo.gl/25SX7K

  11. [19]

    https://github.com /p4lang

    The P4 language repositories. https://github.com /p4lang

  12. [20]

    https://www.druva.co m/blog/the-rise-and-risk-of-byod/

    The rise and risk of BYOD. https://www.druva.co m/blog/the-rise-and-risk-of-byod/

  13. [21]

    https://goo.gl/GmZ1i o

    Samsung BYOD solutions. https://goo.gl/GmZ1i o

  14. [22]

    http://www.samsung.com/global /business/mobile/solution/security/samsung -knox

    Samsung Knox. http://www.samsung.com/global /business/mobile/solution/security/samsung -knox

  15. [23]

    ht tps://goo.gl/Z769MG

    Securing your weakest link: Your mobile devices. ht tps://goo.gl/Z769MG

  16. [24]

    https://goo.gl/zTJaUL

    Security configuration guide: Access control lists, Cisco IOS XE Release 3S. https://goo.gl/zTJaUL

  17. [25]

    https://www.symantec.com/con tent/dam/symantec/docs/data-sheets/endpo int-protection-mobile-for-emm-en.pdf

    Symantec EMM. https://www.symantec.com/con tent/dam/symantec/docs/data-sheets/endpo int-protection-mobile-for-emm-en.pdf

  18. [26]

    https://community.arm.com/developer/ip-p roducts/processors/b/processors-ip-blog/ posts/a-technical-report-on-tee-and-arm- trustzone

    A technical report on TEE and ARM TrustZone. https://community.arm.com/developer/ip-p roducts/processors/b/processors-ip-blog/ posts/a-technical-report-on-tee-and-arm- trustzone

  19. [27]

    https://go o.gl/MuRr66

    Top 21 companies in the BYOD market. https://go o.gl/MuRr66

  20. [28]

    https://source.android.com/security/verifi edboot/

    Verified Boot: Android Open Source Project. https://source.android.com/security/verifi edboot/

  21. [29]

    https://www.air-watch.com/ capabilities/enterprise-mobility-managem ent/

    VMware Airwatch. https://www.air-watch.com/ capabilities/enterprise-mobility-managem ent/

  22. [30]

    What is BYOD and why is it important? https://go o.gl/H71Nji

  23. [31]

    IEEE 802.1x remote authentication dial in user service (RADIUS) usage guidelines, RFC 3580. 2003. https: //www.rfc-editor.org/info/rfc3580

    2003

  24. [32]

    https://github.com/noxrepo/nox, 2012

    Nox. https://github.com/noxrepo/nox, 2012

    2012

  25. [33]

    https://www.sdxcentral.com/project s/beacon/, 2013

    Beacon. https://www.sdxcentral.com/project s/beacon/, 2013

    2013

  26. [34]

    https://noxrepo.github.io/pox-doc/ht ml/, 2017

    Pox. https://noxrepo.github.io/pox-doc/ht ml/, 2017

    2017

  27. [35]

    https://developer.android.com/stud io/command-line/dumpsys, 2018

    dumpsys. https://developer.android.com/stud io/command-line/dumpsys, 2018

    2018

  28. [36]

    https://www.opendaylight.org/, 2018

    OpenDaylight. https://www.opendaylight.org/, 2018. 14

    2018

  29. [37]

    https: //play.google.com/store/apps/details?i d=com.futuremark.pcmark.android.benchmark, 2018

    Pcmark for android benchmark. https: //play.google.com/store/apps/details?i d=com.futuremark.pcmark.android.benchmark, 2018

    2018

  30. [38]

    Aditya, R

    P. Aditya, R. Sen, P. Druschel, S. Joon Oh, R. Benenson, M. Fritz, B. Schiele, B. Bhattacharjee, and T. T. Wu. I-pic: A platform for privacy-compliant image capture. In Proc. MobiSys, 2016

    2016

  31. [39]

    Alzubaidi and J

    A. Alzubaidi and J. Kalita. Authentication of smart- phone users using behavioral biometrics. IEEE Com- munications Surveys& Tutorials,, 18, 2016

    2016

  32. [40]

    C. J. Anderson, N. Foster, A. Guha, J.-B. Jeannin, D. Kozen, C. Schlesinger, and D. Walker. NetKAT: Semantic foundations for networks. In Proc. POPL, 2014

    2014

  33. [41]

    Apthorpe, Y

    N. Apthorpe, Y . Shvartzshnaider, A. Mathur, D. Reis- man, and N. Feamster. Discovering smart home Inter- net of Things privacy norms using contextual integrity. Proceedings of the ACM on Interactive, Mobile, Wear- able and Ubiquitous Technologies (IMWUT), 2, 2018

    2018

  34. [42]

    Backes, S

    M. Backes, S. Bugiel, S. Gerling, and P. von Styp- Rekowsky. Android security framework: Extensible multi-layered access control on android. In Proc. AC- SAC, 2014

    2014

  35. [43]

    Barth, A

    A. Barth, A. Datta, J. C. Mitchell, and H. Nissenbaum. Privacy and contextual integrity: Framework and ap- plications. In Proc. IEEE Symposium on Security and Privacy, 2006

    2006

  36. [44]

    Beckett, R

    R. Beckett, R. Mahajan, T. Millstein, J. Padhye, and D. Walker. Don’t mind the gap: Bridging network- wide objectives and device-level configurations. In Proc. SIGCOMM, 2016

    2016

  37. [45]

    Bosshart, D

    P. Bosshart, D. Daly, G. Gibb, M. Izzard, N. McKe- own, J. Rexford, C. Schlesinger, D. Talayco, A. Vah- dat, G. Varghese, and D. Walker. P4: Programming protocol-independent packet processors. ACM SIG- COMM CCR, 44(3), 2014

    2014

  38. [46]

    Bosshart, G

    P. Bosshart, G. Gibb, H.-S. Kim, G. Varghese, N. McK- eown, M. Izzard, F. Mujica, and M. Horowitz. Forward- ing metamorphosis: Fast programmable match-action processing in hardware for SDN. In Proc. SIGCOMM, 2013

    2013

  39. [47]

    Casado, M

    M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McK- eown, and S. Shenker. Ethane: Taking control of the enterprise. In Proc. SIGCOMM, 2007

    2007

  40. [48]

    Casado, T

    M. Casado, T. Garfinkel, A. Akella, M. Freedman, D. Boneh, N. McKeown, and S. Shenker. SANE: A protection architecture for enterprise networks. InProc. USENIX Security, 2006

    2006

  41. [49]

    Dang-Pham and S

    D. Dang-Pham and S. Pittayachawan. Comparing in- tention to avoid malware across contexts in a BYOD- enabled Australian university: A protection motivation theory approach. Computers & Security, 48, Feb. 2015

    2015

  42. [50]

    Dautenhahn, T

    N. Dautenhahn, T. Kasampalis, W. Dietz, J. Criswell, and V . Adve. Nested kernel: An operating system architecture for intra-kernel privilege separation. In Proc. ASPLOS, 2015

    2015

  43. [51]

    Eberz, K

    S. Eberz, K. B. Rasmussen, V . Lenders, and I. Marti- novic. Evaluating behavioral biometrics for continuous authentication: Challenges and metrics. In Proc. Asi- aCCS, 2017

    2017

  44. [52]

    Ehatisham -ul-Haqa, M

    M. Ehatisham -ul-Haqa, M. A. Azama, U. Naeemb, Y . Amina, and J. Looc. Continuous authentication of smartphone users based on activity pattern recognition using passive mobile sensing. Journal of Network and Computer Applications, 109, 2018

    2018

  45. [53]

    S. K. Fayaz, Y . Tobioka, V . Sekar, and M. Bailey. Bo- hatei: Flexible and elastic DDoS defense. In Proc. USENIX Security, 2015

    2015

  46. [54]

    Fernandes, J

    E. Fernandes, J. Paupore, A. Rahmati, D. Simionato, M. Conti, and A. Prakash. FlowFence: Practical data protection for emerging IoT application frameworks. In Proc. USENIX Security, 2016

    2016

  47. [55]

    D. F. Ferraiolo, D. R. Kuhn, and R. Chandramouli. Role-Based Access Control. Artech House, 2007

    2007

  48. [56]

    D. F. Ferraiolo, R. Sandhu, S. Gavrila, D. R. Kuhn, and R. Chandramouli. Proposed NIST standard for role-based access control. ACM Transactions on Infor- mation and System Security (TISSEC), 3, 2001

    2001

  49. [57]

    Foster, R

    N. Foster, R. Harrison, M. Freedman, C. Monsanto, J. Rexford, A. Story, and D. Walker. Frenetic: A net- work programming language. In Proc. ICFP, 2011

    2011

  50. [58]

    Fratantonio, C

    Y . Fratantonio, C. Qian, P. Chung, and W. Lee. Cloak and dagger: From two permissions to complete control of the UI feedback loop. In Proc. IEEE S&P, 2017

    2017

  51. [59]

    C. K. Georgiadis, I. Mavridis, G. Pangalos, and R. K. Thomas. Flexible team-based access control using contexts. In Proc. SACMAT, 2001

    2001

  52. [60]

    D. Harkins. Simultaneous authentication of equals: A secure, password-based key exchange for mesh net- works. In Proc. SensorComm, 2008. 15

    2008

  53. [61]

    C.-Y . Hong, S. Kandula, R. Mahajan, M. Zhang, V . Gill, M. Nanduri, and R. Wattenhofer. Achieving high uti- lization with software-driven WAN. In Proc. SIG- COMM, 2013

    2013

  54. [62]

    S. Hong, R. Baykov, L. Xu, S. Nadimpalli, and G. Gu. Towards SDN-defined programmable BYOD (bring your own device) security. In Proc. NDSS, 2016

    2016

  55. [63]

    S. Hong, L. Xu, H. Wang, and G. Gu. Poisoning net- work visibility in software-defined networks: New at- tacks and countermeasures. In Proc. NDSS, 2015

    2015

  56. [64]

    S. Jain, A. Kumar, S. Mandal, J. Ong, L. Poutievski, A. Singh, S. Venkata, J. Wanderer, J. Zhou, M. Zhu, J. Zolla, U. Hölzle, S. Stuart, and A. Vahdat. B4: Expe- rience with a globally-deployed software defined W AN. In Proc. SIGCOMM, 2013

    2013

  57. [65]

    Y . J. Jia, Q. A. Chen, S. Wang, A. Rahmati, E. Fer- nandes, Z. M. Mao, and A. Prakash. ContexIoT: To- wards providing contextual integrity to appified IoT platforms. In Proc. NDSS, 2016

    2016

  58. [66]

    X. Jin, X. Li, H. Zhang, N. Foster, J. Lee, R. Soule, C. Kim, and I. Stoica. NetChain: Scale-free sub-RTT coordination. In Proc. NSDI, 2018

    2018

  59. [67]

    X. Jin, X. Li, H. Zhang, R. Soulé, J. Lee, N. Foster, C. Kim, and I. Stoica. NetCache: Balancing key-value stores with fast in-network caching. In Proc. SOSP, 2017

    2017

  60. [68]

    M. T. Jones. Invoking user-space applications from the kernel. https://www.ibm.com/developerworks/l ibrary/l-user-space-apps/index.html , 2018

    2018

  61. [69]

    L. Jose, L. Yan, G. Varghese, and N. McKeown. Com- piling packet programs to reconfigurable switches. In Proc. NSDI, 2015

    2015

  62. [70]

    Katta, M

    N. Katta, M. Hira, C. Kim, A. Sivaraman, and J. Rex- ford. HULA: Scalable load balancing using pro- grammable data planes. In Proc. SOSR, 2016

    2016

  63. [71]

    M. Liu, L. Luo, J. Nelson, L. Ceze, A. Krishnamurthy, and K. Atreya. IncBricks: Toward in-network compu- tation with an in-network cache. In Proc. ASPLOS, 2017

    2017

  64. [72]

    McKeown, T

    N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner. OpenFlow: Enabling innovation in campus networks. ACM SIGCOMM Computer Communication Review, 38, 2008

    2008

  65. [73]

    R. Miao, H. Zeng, C. Kim, J. Lee, and M. Yu. SilkRoad: Making stateful layer-4 load balancing fast and cheap using switching ASICs. In Proc. SIGCOMM, 2017

    2017

  66. [74]

    Monsanto, N

    C. Monsanto, N. Foster, R. Harrison, and D. Walker. A compiler and run-time system for network program- ming languages. In Proc. POPL, 2012

    2012

  67. [75]

    Monsanto, J

    C. Monsanto, J. Reich, N. Foster, J. Rexford, and D. Walker. Composing software-defined networks. In Proc. NDSI, 2013

    2013

  68. [76]

    Morrison, L

    A. Morrison, L. Xue, A. Chen, and X. Luo. Enforcing context-aware BYOD policies with in-network security. In Proc. HotCloud, July 2018

    2018

  69. [77]

    M’Raihi, S

    D. M’Raihi, S. Machani, M. Pei, and J. Rydell. Rfc 6238-totp: Time-based one-time password algorithm. tools.ietf.org, 2011

    2011

  70. [78]

    Nadkarni and W

    A. Nadkarni and W. Enck. ASM: A programmable interface for extending Android security. In Proc. USENIX security, 2014

    2014

  71. [79]

    Narayana, A

    S. Narayana, A. Sivaraman, V . Nathan, P. Goyal, V . Arun, M. Alizadeh, V . Jeyakumar, and C. Kim. Language-directed hardware design for network per- formance monitoring. In Proc. SIGCOMM, 2017

    2017

  72. [80]

    Nauman, S

    M. Nauman, S. Khan, X. Zhang, and J.-P. Seifert. Be- yond kernel-level integrity measurement: Enabling re- mote attestation for the Android platform. In Proc. International Conference on Trust and Trustworthy Computing, 2010

    2010

  73. [81]

    OConnor, W

    T. OConnor, W. Enck, W. M. Petullo, and A. Verma. PivotWall: SDN-based information flow control. In Proc. SOSR, 2018

    2018

  74. [82]

    Parducci

    B. Parducci. eXtensible Access Control Markup Lan- guage (XACML) specification. 2005

    2005

  75. [83]

    S. G. plc. Synchronized security: Best-of-breed defense that’s more coordinated than attacks. https://www.sophos.com/en-us/medialibrary/ gated-assets/white-papers/sophos-security- heartbeat-wpna.pdf

  76. [84]

    Porras, S

    P. Porras, S. Shin, V . Yegneswaran, M. Fong, M. Tyson, and G. Gu. A security enforcement kernel for Open- Flow networks. In Proc. HotSDN, 2012

    2012

  77. [85]

    Reitblatt, M

    M. Reitblatt, M. Canini, A. Guha, and N. Foster. Fat- tire: Declarative fault tolerance for software-defined networks. In Proc. HotSDN, 2013

    2013

  78. [86]

    Schlesinger, M

    C. Schlesinger, M. Greenberg, and D. Walker. Con- current NetCore: From policies to pipelines. In Proc. ICFP, 2014

    2014

  79. [87]

    Y . Shao, X. Luo, and C. Qian. Rootguard: Protecting rooted android phones. IEEE Computer, 47(6), 2014. 16

    2014

  80. [88]

    Shin and G

    S. Shin and G. Gu. Cloudwatcher: Network secu- rity monitoring using OpenFlow in dynamic cloud net- works (or: How to provide security monitoring as a service in clouds?). In Proc. ICNP, 2012

    2012

  81. [89]

    S. Shin, P. Porras, V . Yegneswaran, M. Fong, G. Gu, and M. Tyson. Fresco: Modular composable security services for software-defined networks. In Proc. NDSS, 2013

    2013

  82. [90]

    S. Shin, V . Yegneswaran, P. Porras, and G. Gu. A V ANT- GUARD: Scalable and vigilant switch flow manage- ment in software-defined networks. In Proc. CCS, 2013

    2013

  83. [91]

    Skowyra, L

    R. Skowyra, L. Xu, G. Gu, T. Hobson, V . Dedhia, J. Landry, and H. Okhravi. Effective topology tamper- ing attacks and defenses in software-defined networks. In Proc. DSN, 2018

    2018

  84. [92]

    Sonchack, A

    J. Sonchack, A. Aviv, E. Keller, and J. Smith. Enabling practical software-defined networking security appli- cations with OFX. In Proc. NDSS, 2016

    2016

  85. [93]

    H. Song. Protocol-oblivious forwarding: Unleash the power of SDN through a future-proof forwarding plane. In Proc. HotSDN, 2013

    2013

  86. [94]

    Tolone, G.-J

    W. Tolone, G.-J. Ahn, and T. Pai. Access control in collaborative systems. ACM Computing Surveys, 37, 2005

    2005

  87. [95]

    Ulltveit-Moe and V

    N. Ulltveit-Moe and V . Oleshchuk. Enforcing mobile security with location-aware role-based access control. Security and Communication Networks, 9, 2016

    2016

  88. [96]

    Next generation security with VMware NSX and Palo Alto Networks VM-series

    VMware. Next generation security with VMware NSX and Palo Alto Networks VM-series. In White Paper, 2013

    2013

  89. [97]

    V oellmy, A

    A. V oellmy, A. Agarwal, P. Hudak, N. Feamster, S. Bur- nett, and J. Launchbury. Don’t configure the network, program it! Domain-specific programming languages for network systems. In Proc. SIGCOMM, 2010

    2010

  90. [98]

    X. Wang, K. Sun, Y . Wang, and J. Jing. Deepdroid: Dynamically enforcing enterprise policy on Android devices. In Proc. NDSS, 2015

    2015

  91. [99]

    X. Wang, T. Yu, O. Mengshoel, and P. Tague. Towards continuous and passive authentication across mobile devices: an empirical study. In Proc. WiSec, 2017

    2017

  92. [100]

    Z. Wang, Z. Qian, Q. Xu, Z. M. Mao, and M. Zhang. An untold story of middleboxes in cellular networks. In Proc. SIGCOMM, 2011

    2011

  93. [101]

    Ward and B

    R. Ward and B. Beyer. BeyondCorp: A new approach to enterprise security. USENIX ;login:, 39, 2014

    2014

  94. [102]

    https://www.wi-fi.org/news-events/ newsroom/wi-fi-alliance-introduces-wi-fi -certified-wpa3-security

    Wi-Fi Alliance introduces Wi-Fi Certified WPA3 security. https://www.wi-fi.org/news-events/ newsroom/wi-fi-alliance-introduces-wi-fi -certified-wpa3-security

  95. [103]

    L. Xu, J. Huang, S. Hong, J. Zhang, and G. Gu. At- tacking the brain: Races in the SDN control plane. In Proc. USENIX Security, 2017

    2017

  96. [104]

    R. Ye. Android System Programming: Porting, cus- tomizing, and debugging Android HAL. Packt Publish- ing, 2017

    2017

  97. [105]

    T. Yu, S. K. Fayaz, M. Collins, V . Sekar, and S. Seshan. PSI: Precise security instrumentation for enterprise networks. In Proc. NDSS, 2017

    2017

  98. [106]

    T. Yu, V . Sekar, S. Seshan, Y . Agarwal, and C. Xu. Han- dling a trillion (unfixable) flaws on a billion devices: Rethinking network security for the Internet-of-Things. In Proc. HotNets, 2016

    2016

  99. [107]

    Y . Yuan, D. Lin, R. Alur, and B. T. Loo. Scenario-based programming for SDN policies. In Proc. CoNEXT, 2015

    2015

  100. [108]

    Zahadat, P

    N. Zahadat, P. Blessner, T. Blackburn, and B. Olson. BYOD security engineering: A framework and its anal- ysis. Computers & Security, 55, Nov. 2015. 17

    2015

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.