Problems in using HIP for P2PSIP

Document Sample
Problems in using HIP for P2PSIP Powered By Docstoc
					Problems in using
   Philip Matthews
• Will present 2 different alternatives and the
  problems we discovered.
• Currently trying third approach:
  – Take ideas from HIP, rather than trying to use
    HIP itself.
   Background: Overlay Routing
When establishing a new overlay connection to a peer
behind a NAT or Firewall, often cannot send signaling
directly; must route signaling around overlay.

       Z                                    W

               Most NATs will block msg

                  First Attempt

• Key idea: Add overlay routing to HIP
• To establish new overlay connection:
 1) Establish connection with HIP signaling;
 2) Do additional handshaking at Peer
 Protocol level over HIP connection.

 Protocol being defined by P2PSIP WG to manage the overlay
 and implement a DHT in the overlay.
         Problem: Credentials
• Credential checks are done by Peer Protocol,
  but this is after HIP connections are made.
   – Lots of work done before check is made.
• Would like to do checks earlier, but this
  requires credentials to be carried in I1 and/or
                   RVS                 X
          I1 msg
           J                               Overlay

 All nodes except RVS assumed to be behind a NAT or FW.
   Problem: Routing R1 and R2
 • How to route R1 and R2 back to joining peer J
 • Add new TLVs?
    – Record-Route record node that a HIP msg passes
    – Playback-Route source-routes a HIP msg.
                  RVS                X
         I1 msg
          J        R1 msg                Overlay

All nodes except RVS assumed to be behind a NAT or FW.
Problem: Duplicate Functionality
• Some functions seem to be needed at
  both HIP and Peer Protocol layer.
• Example:
  – Routing hop-by-hop around the overlay
    required at HIP layer to route BEX
  – Routing hop-by-hop around the overlay
    seems to also be needed at Peer Protocol
    layer to route packets for Get and Put
    operations on DHT
   First Attempt: Impressions

• Lots of additions to HIP required:
  – Overlay routing based on HITs
  – Credentials in I1 msg
  – Record-Route TLV in I1 msg
  – Plus other extensions
• Starting to look messy.
          Second Attempt

• Key idea: Carry HIP inside Peer
  – I1, R1, I2, and R2 packets carried inside
    Peer Protocol messages.
  – Overlay routing handled by peer protocol
  – Previous two problems pushed out of HIP
    to peer protocol.
    Problem: D-H exchange
• Peer has to present a credential every
  time it sets up a new connection
  showing that it is allowed to be a
  member of the overlay.
• Given this, is the simple D-H exchange
  of HIP still appropriate?
        Problem: Puzzles

• HIP Puzzle designed to protect against
  DoS attacks
• However, lots of work being done by
  peers in overlay before puzzle is
            Third Attempt

• Don’t use HIP signaling
• Instead, incorporate ideas from HIP
  into Peer Protocol:
  – ID/Locator split            Yes
  – ESP encryption, D-H stuff   Not now
  – Puzzle                      Not now
      More on Third Attempt
• On a peer, applications use an
  “identifier” that looks like an IPv4 or
  IPv6 address to identify a peer.
  – Can allocate ports off this identifier
• These “virtual” addresses and ports are
  then translated to real addresses and
  ports by a “mapping” layer between the
  IP layer and the Transport layer.
               Open Issue
• Expose HIT to IPv6 apps, or expose only an
  IPv6 LSI (as is done to IPv4 apps)?
  – May be advantages to exposing only a IPv6 LSI.
• Using the HIT as the IPv6 Identifier doesn’t
  seem to help a lot.
  – At first blush, helps when sending protocol
    messages with embedded addresses
  – However, receiving node must be able to find the
    node with that HIT -- problematic.

Shared By: