Neighborhood Watch Protocol

1. NeighborhoodWatch Protocol An Address Resolution Protocol for the HID Principal in XIA Cody Doucette Michel Machado John W. Byers

2. BU Network Reading Group, September 17, 2012 eXpressive Internet Architecture (XIA) • Joint venture between BU, CMU, UW-Madison; part of Future Internet Architectures initiative (FIA) • Broad goal is to reform the network stack at “narrow waist”– IP • The Internet needs trustworthiness and evolvability!

3. BU Network Reading Group, September 17, 2012 eXpressive Internet Architecture (XIA) • IP problem: • Focusing on one communication type hinders others • XIA approach: • Modularize communication types so that one architecture can support many (future) paradigms • IP problem: • Using new communication types may require all legacy routers to be updated • XIA approach: • Require backwards-compatibility using widely-accepted types • IP problem: • Numerous security issues: IP address spoofing, IP fragment attacks, … • XIA approach: • Introduce intrinsic security individually for each communication type

4. BU Network Reading Group, September 17, 2012 Three Pillars of XIA • Principal types: autonomous domains, hosts, services, content, and future types • Fallbacks: new types that may not be globally known must include backwards-compatible address

5. BU Network Reading Group, September 17, 2012 eXpressive Internet Protocol (XIP) • New network layer protocol; uses a DAG with principal types to specify multiple paths to destination

6. BU Network Reading Group, September 17, 2012 eXpressive Internet Protocol (XIP) • Express intent when using principal types; this provides for heterogeneity and intrinsic security:

7. BU Network Reading Group, September 17, 2012 Host-to-Host Communication in XIA • Host-to-host communication especially important– required as a fallback edge • Hosts need a way of: • Discovering other hosts in the LAN • Mapping network layer addresses (HIDs) into link layer addresses How can hosts in XIA accomplish this?

8. BU Network Reading Group, September 17, 2012 Motivation Why not extend ARP? • Four edges at every hop in XIP • Using ARP to lookup each edge would slow routing • HIDs do not support network masks • ARP responses would flood all interfaces • XIP values secure link layer addressing • ARP does not guarantee security; “ARP spoofing”

9. BU Network Reading Group, September 17, 2012 Enter: Neighborhood Watch Protocol Defining Characteristics: • Neighborhood assumption: operates under assumption that all hosts that support HIDs in a LAN know of each other • Routing never stops: utilizes RCU for interruption-free lookups • Supports evolution: works in conjunction with HID principal only, not a companion to XIP

10. BU Network Reading Group, September 17, 2012 Enter: Neighborhood Watch Protocol Defining Characteristics: • Efficiency: begets low network overhead compared to using ARP • Robustness: prevents data inconsistencies due to node failure and network partitioning • Scalability: constructs an eventually consistent LAN of arbitrary size

11. BU Network Reading Group, September 17, 2012 Functionality What can NWP do? • Address resolution • Failure detection • Efficient table synchronization (WIP) • Link-layer addressing security (WIP)

12. BU Network Reading Group, September 17, 2012 Functionality What can NWP do? • Address resolution • Failure detection • Efficient table synchronization (WIP) • Link-layer addressing security (WIP)

13. BU Network Reading Group, September 17, 2012 Address Resolution: Neighborhood View Neighbor list contains hosts connected via a common LAN interface Neighbors here: • AE, BE, CE • AW, CW

14. BU Network Reading Group, September 17, 2012 Address Resolution: Announcing NWP Announcement Packet Header Hosts can broadcast announcements to learn about neighbors ** Assuming a 48-bit MAC address. Announcement contains all HIDs that correspond to a single hardware address

15. BU Network Reading Group, September 17, 2012 Address Resolution: Responding Neighbor lists are sent in response to an announcement NWP Neighbor List Packet Header List tells receiver about neighbors and associatedhardware addresses

16. BU Network Reading Group, September 17, 2012 Functionality What can NWP do? • Address resolution • Failure detection • Efficient table synchronization (WIP) • Link-layer addressing security (WIP)

17. BU Network Reading Group, September 17, 2012 Failure Detection Neighbors should be monitored to observe failure or disconnection Goals of the NWP failure detector: • Completeness • Accuracy • Speed • Scalability • Distribution

18. BU Network Reading Group, September 17, 2012 Failure Detection: Distribution Consider: Two nodes cannot communicate due to temporary packet loss. These nodes should retain neighbor status. If two neighbors cannot connect, the source uses a set K of other neighbors to investigate This distributes the decision of failure across |K|+1 nodes Distributed failure detector based on previous work by Gupta et al., PODC ‘01 http://cdn.dailyclipart.net/wp-content/uploads/medium/clipart0252.jpg

19. BU Network Reading Group, September 17, 2012 Failure Detection: Two Nodes Source pings random neighbors at set intervals; destination sends an ack upon receipt Senders include lower 32 bits of their clock to synchronize NWP Ping/Ack Packet Header

20. BU Network Reading Group, September 17, 2012 Failure Detection: Three Nodes • If no ack is received, source uses other neighbors to investigate potentially failed destination • If no response is heard after a set time, destination is marked as inactive NWP Request/Investigative Ping Packet Header

21. BU Network Reading Group, September 17, 2012 Failure Detection: Packet Types NWP Ping Request NWP Ping Ni Nj Ni Nj • Nx NWP Request Ack NWP Ack Ni Nj Ni Nj • Nx NWP Investigative Ping Ni Nj • Nx

22. BU Network Reading Group, September 17, 2012 Failure Detection: Algorithm Similar diagram found in Gupta et al., 2001

23. BU Network Reading Group, September 17, 2012 Failure Detection: Conflict Resolution Question: How does the NWP failure detector reconcile conflicting reports about the status of a neighbor? Answer: • Neighbor tables hold local/remote times at which neighbor’s status was recorded • If a neighbor fails, we make an inference about what time it failed • We resolve conflicts by taking most up-to-date information Node A Neighbor Table Node C Neighbor Table

24. BU Network Reading Group, September 17, 2012 Failure Detection: Mass Failure Question: All neighborhood tables are equal before a network partition takes place. How will a node remove all entries from its table that are no longer accessible? Answer: • In most cases, a mass disconnection is handled in the same way that an individual disconnection is handled: gradually • The detection scheme promises only eventual consistency http://drtom.schank.ch/talks/2010/12/NoSQL/CAP/NetworkPartition03.svg

25. BU Network Reading Group, September 17, 2012 Failure Detection: Mass Failure, Continued • However, there is a mechanism for detecting when a mass failure might have occurred. Consider the case where D tries to monitor E: • If D→E communication fails, A, B, and C are of no help here since they are in a separate partition • However, D should recognize that it received no response from A, B, and C A A D D B B E E C C

26. BU Network Reading Group, September 17, 2012 Failure Detection Neighbors should be monitored to observe failure or disconnection Goals of the NWP failure detector: • Completeness: • Accuracy: • Speed: • Distribution: • Scalability:

27. BU Network Reading Group, September 17, 2012 Failure Detection Neighbors should be monitored to observe failure or disconnection Goals of the NWP failure detector: • Completeness: ✓ • Accuracy: ✓ • Speed: ✓ • Distribution: ✓ • Scalability: ✓ → independent of LAN size

28. BU Network Reading Group, September 17, 2012 Functionality What can NWP do? • Address resolution • Failure detection • Efficient table synchronization (WIP) • Link-layer addressing security (WIP) More to come!

29. BU Network Reading Group, September 17, 2012 References • “XIA: An Architecture for an Evolvable and Trustworthy Internet” by Hyeontaek Lim. In The 9th USENIX Symposium on Networked Systems Design and Implementation (NSDI’12) (San Jose, CA), April 25-27, 2012 • “On Scalable and Efficient Distributed Failure Detectors” by Indranil Gupta, Tushar D. Chandra, and Germán S. Goldszmidt. In Proceedings of the Twentieth Annual ACM Symposium on Principles of Distributed Computing, 2001. • “XIA: Efficient Support for Evolvable Internetworking” by Dongsu Han, Ashok Anand, FahadDogar, Boyan Li, Hyeontaek Lim, Michel Machado, ArvindMukundan, Wenfei Wu, AdityaAkella, David G. Andersen, John W. Byers, SrinivasanSeshan, and Peter Steenkiste. In Proc. 9th USENIX NSDI, (San Jose, CA), Apr. 2012.