Download Neighborhood Watch Protocol

NEIGHBORHOOD
WATCH PROTOCOL
An Address Resolution Protocol
for the HID Principal in XIA
Cody Doucette
Michel Machado
John W. Byers
BU Network Reading Group, September 17, 2012
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
• Principal types: autonomous domains, hosts, services,
content, and future types
• Fallbacks: new types that may not be globally known must
include backwards-compatible address
BU Network Reading Group, September 17, 2012
5
eXpressive Internet Protocol (XIP)
• New network layer protocol; uses a DAG with principal types
to specify multiple paths to destination
BU Network Reading Group, September 17, 2012
6
eXpressive Internet Protocol (XIP)
• Express intent when using principal types; this provides for
heterogeneity and intrinsic security:
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
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, 2012
9
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, 2012
10
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, 2012
Functionality
What can NWP do?
• Address resolution
• Failure detection
• Efficient table synchronization (WIP)
• Link-layer addressing security (WIP)
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
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
NWP Announcement Packet Header
Bit
Offset
0–7
8 – 15
0
Version
Type
16
Number of HIDs
Hardware Addr. Len.
32
48
Hardware Address
of Announcing Host**
64
80
HID1
…
…
…
HIDN
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
BU Network Reading Group, September 17, 2012
15
Address Resolution: Responding
NWP Neighbor List Packet Header
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
Neighbor lists are sent
in response to an
announcement
List tells receiver about
neighbors and associated
hardware addresses
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)
16
BU Network Reading Group, September 17, 2012
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, 2012
18
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
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
NWP Ping/Ack Packet Header
Bit
Offset
0–7
8 – 15
0
Version
Type
16
Hardware Addr. Len.
Reserved
32
48
Sender’s Clock
(lower 32 bits)
64
Source Host Hardware Address
…
Destination Host Hardware Address
BU Network Reading Group, September 17, 2012
20
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
Bit
Offset
0–7
8 – 15
0
Version
Type
16
Hardware Addr. Len.
Reserved
32
48
Sender’s Clock
(lower 32 bits)
64
Source Host Hardware Address
…
Destination Host Hardware Address
…
Investigative Host Hardware Address
BU Network Reading Group, September 17, 2012
21
Failure Detection: Packet Types
NWP Ping Request
NWP Ping
Nj
Ni
Ni
Nj
NWP Request Ack
NWP Ack
Ni
Nx
Nj
Ni
Nx
Nj
NWP Investigative Ping
Ni
Nx
Nj
BU Network Reading Group, September 17, 2012
Failure Detection: Algorithm
Similar diagram found in Gupta et al., 2001
22
BU Network Reading Group, September 17, 2012
23
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
Status
Node
My Clock
Remote Clock
Status
Node
My Clock
Remote Clock
Up
B
500
530
Up
B
480
565
Down
B
538
568
BU Network Reading Group, September 17, 2012
24
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?
http://drtom.schank.ch/talks/2010/12/NoSQL/CAP/NetworkPartition03.svg
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, 2012
25
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
BU Network Reading Group, September 17, 2012
26
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, 2012
27
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
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!
28
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.