ID-LOC Proposal

1
ID-LOC Proposal

• Philip Matthews
• Eric Cooper
• Alan Johnston
• Avaya
• With contributions from Cullen Jennings,
• David Bryan, and Bruce Lowekamp

2
Not a Peer Protocol proposal !

• ID-LOC proposed addition to the Peer Protocol
  (i.e., Reload or whatever).
• ID-LOC
• Some selected ideas from HIP
• Plus a few new ideas

3
Relationship to HIP

• Take from HIP
• Identifiers that look like IP addresses
• NAT traversal done once for all apps
• TCP over UDP (for NAT traversal)
• Not taken (for now)
• HIP signaling (use Peer Protocol instead)
• Encrypting all data packets using ESP
• New
• Domain names for peers

4
What ID-LOC allows
N A T
N A T
earth.example.com
saturn.example.com
Overlay Example.com
Browser
Web server
5
Tech Details in 3 slides (1)

• Assign domain names to overlays and peers
• saturn.example.com
• DHT holds mapping between peers domain name and
  peers peer ID
• saturn.example.com gt 0xA3F26E

6
Tech Details in 3 slides (2)

• Applications dont use Peer IDs directly.
  Instead, use special IP addresses (LSIs).
• An LSI is a shorthand for a Peer ID
• Unlike peer IDs, an LSI can be used anywhere a
  real IP address can be used
• Taken from special address range
• ORCHID range (RFC 4843) for IPv6
• Perhaps 1.x.x.x for IPv4

7
Tech Details in 3 slides (3)

• NAT Traversal (ICE, etc) done for all
  applications by Peer Protocol (w/ ID-LOC
  extensions)
• Apps dont need to worry about this
• Application data transport protocol
  encapsulated inside UDP for NAT traversal reasons

HTTP
TCP
UDP
IP
8
Implementation

• One option is to implement using standard VPN
  client implementation techniques.

9
Advantages

• Turns a p2p overlay into a VPN
• Like VPNs, applications dont need to change to
  work in an overlay
• Preserves the existing user interface ( domain
  names) and existing application interface (
  sockets and use of IP addresses)
• NAT traversal handled in one place
• Apps dont need NAT traversal code
• No need for endless ICE for protocol X drafts