Preferred Alternatives for Tunnelling HIP (PATH) <draft-nikander-hip-path-01.txt> P. Nikander, H. Tschofenig, X. Fu, T. Henderson

Idea Allow HIP to traverse LEGACY NA(P)Ts by reusing EXISTING mechanisms Goal: To allow HIP protocol exchanges between two HIP endpoints to traverse NATs Mainly for standard ESP-mode encapsulation How: Use UDP encapsulation for HIP signaling and data messages Introduce a new (S-)UDP-REA parameter in HIP signaling messages To support the case where DS/DR we use the RVS functionality (as well as HIP endpoints) to support this extension Such extended RVS servers  also called “PATH” servers HIP endpoints accessing this info  “PATH” clients

The UDP-REA parameter UDP-REA: UDP encapsulated REAdress Idea: Used in To detect existence of NA(P)Ts Mainly, consists of “lifetime + Hashed value” Hash = PRF(RANDOM | Source IP | Destination IP | Source Port | Destination Port) Used in R1-I2 signaling messages in HIP base exchanges RVS/PATH registrations relayed HIP base exchange thru RVS/PATH server UPDATE messages in RVS/PATH registration HIP base UPDATE messages

The S-UDP-REA Parameter S-UDP-REA: “Secure” UDP-REAdress Idea: Reuse other (external) mechanism to discover the NA(P)T address External mechanism can be STUN, TURN, MIDCOM, or NSIS NATFW NSLP Then integrity-protected UDP-REA parameter can be included in the HIP I1-R2 signaling messages This also allows HIP traversal of certain firewalls

Next Steps ?

Questions?