60 likes | 164 Views
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
E N D
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: • 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 • ?