1. September 11, 2006 INM Workshop, SIGCOMM 2006 On Information Hiding and Network Management Kenneth L. Calvert and James Griffioen Laboratory for Advanced Networking Department of Computer Science University of Kentucky (A Position Paper) Thanks: Cisco, Kentucky Science and Eng. Foundation

2. September 11, 2006 INM Workshop, SIGCOMM 2006 The Network Management Tussle m Service Providers have to: q compete with each other q cooperate with each other m Network Management requires information q About the network being managed q About the rest of the Internet m Providers want to hide information about their networks

3. September 11, 2006 INM Workshop, SIGCOMM 2006 Why Hide Information? m Competitive Pressures q Reveal as little as possible about business practices, customer relationships m Customer Privacy q Concerns about possible repercussions of revealing, e.g. communication patterns m Safety and Security q Detailed information about a provider’s system may make it easier to attack.

4. September 11, 2006 INM Workshop, SIGCOMM 2006 Why Not Hide Information? m It is useful for network management: q Where are the packets being dropped? q What is the maximum number of dropped packets in this part of the network? q How many routers have seen packets sent to strange ports? m It is also useful for applications/users generally: q Where are the packets being dropped? q Which end-to-end paths share congested links? q What is the maximum 5-sec average queue length along this path? q What is the maximum loss rate experienced by any receiver?

5. September 11, 2006 INM Workshop, SIGCOMM 2006 Existing Network Mgmt (SNMP) m Low-level interface to available information q Get/Set q One-to-one communication model q Higher-level functions tend to be vendor-specific m Inadequate trust model q Choose between insecure or heavyweight authentication q Signature verification overhead opens DoS possibilities m Scalability issues (See also [IAB 2004]) q No convenient way to probe a group of nodes q Hard to manage policies for large numbers of nodes SNMP cannot support a NM paradigm shift!

6. September 11, 2006 INM Workshop, SIGCOMM 2006 Granting Access to Information m Per Session (well-known approach) q Establish a session (a heavyweight operation) q Authenticate party at other end (at an additional cost) q Determine authorization of that party for each operation based on identity q Can support multiple privilege levels But group operations are very expensive m Per Packet (not yet supported) q Lightweight determination of packet authorization class Based on geometry of the system Not on packet contents q Read information from multiple nodes with a single packet

7. September 11, 2006 INM Workshop, SIGCOMM 2006 What is needed? (aka: our position) q Per-packet Access: Any packet should be able to request (read) information from any router. q Minimal Policy: Minimize distinctions among packets regarding access to information facilities. q Processed Information: Needs to be possible to collect and process data (e.g., perform aggregation/summarization) to hide information and/or improve scalability. q Information Hiding: Information may be modified as it crosses a provider’s boundary, allowing providers to control how data is made available (exposed) to the outside world. Note: Existing heavyweight mechanisms can still be used when needed. For Users For Providers

8. September 11, 2006 INM Workshop, SIGCOMM 2006 Assumptions m Providers manage domains q Domains define information hiding boundaries m Nodes (routers/end systems) are either inside or outside a given domain m Nodes inside the domain with links to one or more nodes outside the domain are border routers m Links connecting border routers in different domains are known border links m Packets get lower authorization if they cross a border link Local (Inside) Domain External (Outside) Domain Border Routers The rest of the World Border Links

9. September 11, 2006 INM Workshop, SIGCOMM 2006 Techniques for Hiding while Exposing m Aggregation m Anonymization m Abstraction Implementation Context: Ephemeral State Processing (ESP) m Supports simple distributed computations w/state m Operates at line-speed (per-packet processing, near the fast path) m ESP-NM: read-access to (some) MIB variables

10. September 11, 2006 INM Workshop, SIGCOMM 2006 Ephemeral State Store m Information persists for a fixed time , then vanishes q   a few seconds q Stored information cannot be refreshed m An associative store q Binds tags to values (partial function ƒ) q Semantics: put(t, v): establishes ƒ. t = v get(t): if ƒ defined at t, return ƒ.t ; else return null m Users choose tags randomly

11. September 11, 2006 INM Workshop, SIGCOMM 2006 Aggregation m Goal: Hide individual values collected from a set of nodes m Idea: use an aggregation function to compute a “representative” value q Example Functions: Max, Min, Avg, Sum, etc … m Example Uses: q Identify the receiver with max loss rate in a group q Find the path with shortest average queue length q Compute the overall network load m Advantages: q Hides information q Simplifies the interface: less information to deal with q Distributes processing

12. September 11, 2006 INM Workshop, SIGCOMM 2006 Aggregation Implementation (using ESP-NM) m Two (triggered) phases 1. Establish child counts at every router on the path to the monitor node 2. Send individual values along with aggregation operation (e.g., max, min, sum, etc) q Example: Collect minimum value from a set of receivers

13. September 11, 2006 INM Workshop, SIGCOMM 2006 Feedback Aggregation (Phase 1) S D B r1 C A r2r3 E Time=1 COUNT Operands: Counter tag c Threshold value 1

14. September 11, 2006 INM Workshop, SIGCOMM 2006 Feedback Aggregation (Phase 1) S D B r1 C A r2r3 E (c,1) Time=2 COUNT

15. September 11, 2006 INM Workshop, SIGCOMM 2006 Feedback Aggregation (Phase 1) S D B r1 C A r2r3 E (c,1) Time=3 COUNT

16. September 11, 2006 INM Workshop, SIGCOMM 2006 Feedback Aggregation (Phase 1) S D B r1 C A r2r3 E (c,2)(c,1) Time=4 COUNT

17. September 11, 2006 INM Workshop, SIGCOMM 2006 Feedback Aggregation (Phase 1) S D B r1 C A r2r3 E (c,2) (c,1) (c,2) Time=5 COUNT

18. September 11, 2006 INM Workshop, SIGCOMM 2006 Feedback Aggregation (Phase 1) S D B r1 C A r2r3 E (c,2) (c,1) (c,3) Time=6

19. September 11, 2006 INM Workshop, SIGCOMM 2006 Feedback Aggregation (Phase 2) S D B r1 C A r2r3 E (c,2) (c,1) (c,3) Time=7

20. September 11, 2006 INM Workshop, SIGCOMM 2006 Feedback Aggregation (Phase 2) S D B r1 C A r2r3 E (c,2) (c,1) (c,3) Time=8

21. September 11, 2006 INM Workshop, SIGCOMM 2006 Feedback Aggregation (Phase 2) S D B r1 C A r2r3 E (c,2) (c,1) (c,3) 3 Time=9 COLLECT

22. September 11, 2006 INM Workshop, SIGCOMM 2006 Feedback Aggregation (Phase 2) S D B r1 C A r2r3 E (c,1) (v,3) (c,1) (c,3) 2 (c,2) Time=10

23. September 11, 2006 INM Workshop, SIGCOMM 2006 Feedback Aggregation (Phase 2) S D B r1 C A r2r3 E (c,1) (c,3) 5 (c,1) (v,3) (c,1) (v,2) Time=11

24. September 11, 2006 INM Workshop, SIGCOMM 2006 Feedback Aggregation (Phase 2) S D B r1 C A r2r3 E (c,1) (c,2) (v,5) (c,1) (v,3) (c,1) (v,2) 2 Time=12

25. September 11, 2006 INM Workshop, SIGCOMM 2006 Feedback Aggregation (Phase 2) S D B r1 C A r2r3 E (c,1) (v,2) (c,1) (v,3) (c,1) (v,2) 4 Time=13

26. September 11, 2006 INM Workshop, SIGCOMM 2006 Feedback Aggregation (Phase 2) S D B r1 C A r2r3 E (c,1) (c,0) (v,2) (c,1) (v,3) (c,1) (v,2) 2 Time=14

27. September 11, 2006 INM Workshop, SIGCOMM 2006 Feedback Aggregation (Phase 2) S D B r1 C A r2r3 E (c,1) (c,0) (v,2) (c,1) (v,3) (c,0) (v,2) 2 Time=15

28. September 11, 2006 INM Workshop, SIGCOMM 2006 Feedback Aggregation (Phase 2) S D B r1 C A r2r3 E (c,1) (c,0) (v,2) (c,0) (v,2) (c,0) (v,2) 2 Time=16

29. September 11, 2006 INM Workshop, SIGCOMM 2006 Feedback Aggregation (Result) S D B r1 C A r2r3 E (c,0) (v,2) (c,0) (v,2) (c,0) (v,2) (c,0) (v,2) 2 Time=17

30. September 11, 2006 INM Workshop, SIGCOMM 2006 Anonymization m Goal: Obscure the identity of network elements while maintaining the ability to differentiate among nodes, domains, etc. m Idea: Return anonymized data, but maintain (locally) the mapping between anonymized values and real values q Think cookies m Example Uses: q Find most heavily loaded router along a path (without revealing its identity), then query that router for additional info q Determine whether two paths traverse the same domain without revealing which domain m Advantages: q Allows providers to hide private information while releasing enough information for users to differentiate/compare/query internal nodes

31. September 11, 2006 INM Workshop, SIGCOMM 2006 Anonymization Implementation (using ESP-NM) m Anonymization can occur: q At the node that creates the response, OR q At a border router (similar to NAT) m Similarly, identity instantiation occurs: q At the node that anonymized value q At the border router that anonymized the value m Issue: routing to anonymized nodes q Send to same destination as the original information request so the packet follows the same path, OR q Border routers replace source address with their address

32. September 11, 2006 INM Workshop, SIGCOMM 2006 Abstraction m Goal: View a group of nodes as a single entity m Idea: Domain administrator defines virtual entities, border routers create the illusion of a single entity m Example Entities: Virtual path from the ingress to egress of a domain, or the domain looks like a virtual node m Example Uses: q Return the loss rate of the internal path across a domain as if it were a single link q Compute the delay across the virtual path connecting the ingress and egress points of a domain m Advantages: q Hides identities of group members q Allows set of network elements to be treated as a single element

33. September 11, 2006 INM Workshop, SIGCOMM 2006 Abstraction Implementation (using ESP-NM) m "Push" a new ESP computation on entry to a domain, and "Pop"/use the result on exit from the domain m Routers know when a packet is entering and exiting a domain m Example: packet finds max link delay q Upon entry, border router pushes “add ” operation to sum delays of links inside the domain q Upon exit, border router pops computed delay value for the path, and uses it as one value in the original ESP request for link delay

34. September 11, 2006 INM Workshop, SIGCOMM 2006 Dangers/Concerns m Are additional techniques required? m How can exposed information be misused? m Can border transformations be implemented efficiently (DoS-free)? m Do network management packets really need fast-path processing? m Is read-only sufficiently useful?

35. September 11, 2006 INM Workshop, SIGCOMM 2006 Summary m A tussle now exists among providers and (other) potential users of network information q Network information is not just for network administrators m NM paradigm shift demands new capabilities (per-packet access, simple processing, info hiding) m Proposed solution based on Ephemeral State Processing q Make (some) management information available to all q Processing functions: Aggregation, Anonymization, Abstraction q Some (ESP) operations implemented in every router, on or near fast path q Sanitizing operations implemented at domain borders

36. September 11, 2006 INM Workshop, SIGCOMM 2006 Questions?

37. September 11, 2006 INM Workshop, SIGCOMM 2006 Filtering (special form of aggregation?) m Goal: Hide unimportant (filtered) values m Idea: Report individual values from a group of nodes that pass a filter test. m Example Filters: Value > (Threshold = 0.5) m Example Uses: q Identify/monitor heavily loaded routers q Load balance across lightly loaded links or servers m Benefits: same as Aggregation

38. September 11, 2006 INM Workshop, SIGCOMM 2006 Fundamental Paradigm Shifts m Openness: E2E Applications and providers need global access to network information. m Convenient Interfaces: Users want convenient methods for accessing information across a set of nodes, not just a single node. m Scalable Mechanisms: Users want to efficiently access information across a set of nodes m Read Access Only: Users want to “see the information under the covers”, not change it.