Problems in using HIP for P2PSIP Philip Matthews Avaya

Overview 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. X NAT Z W Y Most NATs will block msg

First Attempt draft-matthews-p2psip-hip-hop-00 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.

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 I2. X Z W Y All nodes except RVS assumed to be behind a NAT or FW. RVS J I1 msg

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 through –Playback-Route source-routes a HIP msg. Overlay X Z W Y RVS J All nodes except RVS assumed to be behind a NAT or FW. I1 msg R1 msg

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 messages. –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 draft-hautakorpi-p2psip-with-hip-01 Key idea: Carry HIP inside Peer Protocol –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 exchanged.

Third Attempt draft-matthews-p2psip-id-loc-00 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.