Download - Neighborhood Watch Protocol
NEIGHBORHOODWATCH PROTOCOLAn Address Resolution Protocolfor the HID Principal in XIA
Cody DoucetteMichel MachadoJohn W. Byers
2
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, 2012
3
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, 2012
4
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
5
• 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, 2012
6
• Express intent when using principal types; this provides for heterogeneity and intrinsic security:
eXpressive Internet Protocol (XIP)
BU Network Reading Group, September 17, 2012
7
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, 2012
8
MotivationWhy 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, 2012
9
Enter: Neighborhood Watch ProtocolDefining 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, 2012
10
Enter: Neighborhood Watch ProtocolDefining 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, 2012
11
FunctionalityWhat can NWP do?
• Address resolution• Failure detection• Efficient table synchronization (WIP)• Link-layer addressing security (WIP)
BU Network Reading Group, September 17, 2012
12
FunctionalityWhat can NWP do?
• Address resolution• Failure detection• Efficient table synchronization (WIP)• Link-layer addressing security (WIP)
BU Network Reading Group, September 17, 2012
13
Address Resolution: Neighborhood View
Neighbor list contains hosts connected via a common LAN interface
Neighbors here:• AE, BE, CE
• AW, CW
BU Network Reading Group, September 17, 2012
14
Address Resolution: Announcing
Hosts can broadcast announcements to learn about neighbors
Bit Offset 0 – 7 8 – 15
0 Version Type
16 Number of HIDs Hardware Addr. Len.
32Hardware Address
of Announcing Host**486480 HID1
… …
… HIDN
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, 2012
15
Address Resolution: Responding
Neighbor lists are sent in response to an announcement
Bit Offset 0 – 7 8 – 15
0 Version Type
16 Number of HIDs Hardware Addr. Len.
32 HID1 Num1 HA11 … HA1Num1
… …… HIDN NumN HAN1 … HANNumN
List tells receiver about neighbors and associated hardware addresses
NWP Neighbor List Packet Header
BU Network Reading Group, September 17, 2012
16
FunctionalityWhat can NWP do?
• Address resolution• Failure detection• Efficient table synchronization (WIP)• Link-layer addressing security (WIP)
BU Network Reading Group, September 17, 2012
17
Failure DetectionNeighbors 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, 2012
18
Failure Detection: DistributionConsider: 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
BU Network Reading Group, September 17, 2012
19
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 – 7 8 – 15
0 Version Type
16 Hardware Addr. Len. Reserved
32 Sender’s Clock(lower 32 bits)48
64 Source Host Hardware Address
… Destination Host Hardware Address
NWP Ping/Ack Packet Header
BU Network Reading Group, September 17, 2012
20
Failure Detection: Three Nodes
Bit Offset 0 – 7 8 – 15
0 Version Type
16 Hardware Addr. Len. Reserved
32 Sender’s Clock(lower 32 bits)48
64 Source Host Hardware Address
… Destination Host Hardware Address
… Investigative Host Hardware Address
NWP Request/Investigative Ping Packet HeaderIf 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, 2012
21
Failure Detection: Packet Types
BU Network Reading Group, September 17, 2012
Ni NjNx
NWP Ping Request
NWP Request Ack
Ni NjNx
NWP Investigative Ping
Ni NjNx
Ni Nj
NWP Ping
Ni Nj
NWP Ack
22
Failure Detection: Algorithm
BU Network Reading Group, September 17, 2012
Similar diagram found in Gupta et al., 2001
23
Failure Detection: Conflict ResolutionQuestion: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
Status Node My Clock Remote Clock
Up B 500 530
Down B 538 568
Status Node My Clock Remote Clock
Up B 480 565
BU Network Reading Group, September 17, 2012
24
Failure Detection: Mass FailureQuestion: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
BU Network Reading Group, September 17, 2012
25
• 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
Failure Detection: Mass Failure, Continued
B
C
AD
E
BU Network Reading Group, September 17, 2012
B
C
AD
E
26
Failure DetectionNeighbors 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, 2012
27
Failure DetectionNeighbors should be monitored to observe failure or disconnection
Goals of the NWP failure detector:• Completeness: ✓• Accuracy: ✓• Speed: ✓• Distribution: ✓• Scalability: ✓
→ independent of LAN size
BU Network Reading Group, September 17, 2012
28
FunctionalityWhat 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, 2012
29
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, 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. 2012.
BU Network Reading Group, September 17, 2012