Problems in using HIP for P2PSIP

1. Problems in using HIP for P2PSIP Philip Matthews Avaya philip_matthews@magma.ca

2. 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.

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

4. First Attemptdraft-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.

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

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

7. 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

8. 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.

9. Second Attemptdraft-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.

10. 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?

11. Problem: Puzzles • HIP Puzzle designed to protect against DoS attacks • However, lots of work being done by peers in overlay before puzzle is exchanged.

12. Third Attemptdraft-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

13. 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.

14. 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.