NEIGHBORHOOD WATCH PROTOCOL An Address Resolution Protocol for the HID Principal in XIA Cody Doucette Michel Machado John W. Byers

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! BU Network Reading Group, September 17,

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 BU Network Reading Group, September 17,

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

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

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

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? BU Network Reading Group, September 17,

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 BU Network Reading Group, September 17,

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 BU Network Reading Group, September 17,

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 BU Network Reading Group, September 17,

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

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

Address Resolution: Neighborhood View Neighbor list contains hosts connected via a common LAN interface Neighbors here: A E, B E, C E A W, C W BU Network Reading Group, September 17,

Address Resolution: Announcing Hosts can broadcast announcements to learn about neighbors Bit Offset 0 – 78 – 15 0VersionType 16 Number of HIDsHardware Addr. Len. 32 Hardware Address of Announcing Host** HID 1 …… …HID N Announcement contains all HIDs that correspond to a single hardware address NWP Announcement Packet Header ** Assuming a 48-bit MAC address. BU Network Reading Group, September 17,

Address Resolution: Responding Neighbor lists are sent in response to an announcement Bit Offset 0 – 78 – 15 0VersionType 16 Number of HIDsHardware Addr. Len. 32 HID 1 Num 1 HA 11 … HA 1Num 1 … … … HID N Num N HA N1 … HA NNum N List tells receiver about neighbors and associated hardware addresses NWP Neighbor List Packet Header BU Network Reading Group, September 17,

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

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

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 BU Network Reading Group, September 17,

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 Bit Offset 0 – 78 – 15 0VersionType 16 Hardware Addr. Len.Reserved 32 Senders Clock (lower 32 bits) 48 64Source Host Hardware Address …Destination Host Hardware Address NWP Ping/Ack Packet Header BU Network Reading Group, September 17,

Failure Detection: Three Nodes Bit Offset 0 – 78 – 15 0VersionType 16 Hardware Addr. Len.Reserved 32 Senders Clock (lower 32 bits) 48 64Source Host Hardware Address …Destination Host Hardware Address …Investigative Host Hardware Address NWP Request/Investigative Ping Packet Header 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 BU Network Reading Group, September 17,

Failure Detection: Packet Types BU Network Reading Group, September 17, 2012 NiNi NjNj NxNx NWP Ping Request NWP Request Ack NiNi NjNj NxNx NWP Investigative Ping NiNi NjNj NxNx NiNi NjNj NWP Ping NiNi NjNj NWP Ack 21

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

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 neighbors 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 TableNode C Neighbor Table StatusNodeMy ClockRemote Clock UpB DownB StatusNodeMy ClockRemote Clock UpB BU Network Reading Group, September 17,

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 BU Network Reading Group, September 17,

However, there is a mechanism for detecting when a mass failure might have occurred. Consider the case where D tries to monitor E: If DE 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 Failure Detection: Mass Failure, Continued BU Network Reading Group, September 17,

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

Failure Detection BU Network Reading Group, September 17,

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

References XIA: An Architecture for an Evolvable and Trustworthy Internet by Hyeontaek Lim. In The 9th USENIX Symposium on Networked Systems Design and Implementation (NSDI12) (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, XIA: Efficient Support for Evolvable Internetworking by Dongsu Han, Ashok Anand, Fahad Dogar, Boyan Li, Hyeontaek Lim, Michel Machado, Arvind Mukundan, Wenfei Wu, Aditya Akella, David G. Andersen, John W. Byers, Srinivasan Seshan, and Peter Steenkiste. In Proc. 9th USENIX NSDI, (San Jose, CA), Apr BU Network Reading Group, September 17,