Problems in using HIP for P2PSIP Philip Matthews Avaya email@example.com 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. Z W Most NATs will block msg X Y 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. 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. RVS X W I1 msg J Overlay Y Z 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 through – Playback-Route source-routes a HIP msg. RVS X W I1 msg J R1 msg Overlay Y Z 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 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.