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

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

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

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

5. Next Steps ?

6. Questions?