Robert Moskowitz wrote: Hi,
ESP Transport in a bound, end-to-end operation or ESP Tunnel with HITS (or LSI?) explicit.Developers have reported challenges in using what we have been calling BEET mode, and have pointed out that if explicit tunnels were used, then the special HIP "optimization" (? right word) of Transport mode would be avoided.I have at least two technical problems with use of tunnel mode:What is enumerated in the tunnel? HITs always or HITs for IPv6 apps and LSIs for IPv4? (as we have demonstarted that IPv4 apps work well over HIP over IPv6). If HITs how will this work for IPv4? I suspect that someone can explain how this could 'work'?
We have two choices: a) Let the tunnel enumerate both LSI and HITsb) Let the tunnel enumerate only HITs. LSIs must be translated locally to HITs as with BEET.
Option (a) is bad because LSIs are supposed to be local. So I'd vote for option (b).
Would there be expectations on tunnel behaviour that would have to be negotiated?
I think we should modularize negotiation to support different protocols (ESP vs. AH vs. some other like S-RTP) and their modes (tunnel vs. transport vs. beet).
My basic philosophy was ESP transport was used as a 'short hand' for the HIP connection between two hosts. That HIP is not a key negotiation for ESP, but that ESP is used operationally to simplify HIP (not to develop YAP) with SPIs being pointers to the underlying HITs (did I remember that right? :) ).I can see where the process between two hosts is a tunneling process and in that HIP is used to secure the tunnel, but here the tunnel is not coupled to HIP but rather the process between two hosts that uses HIP. Does that make enough sense?These are reasonable questions that have been asked of me over the past year, and I would like to get some other's views.
Yes, it makes sense.