Re: [Hipsec] I-D Action:draft-ietf-hip-over-hip-02.txt

[Ari Keranen <[e-mail]>]

Hi Tobi,

Thanks for the review! Comments inline.

On 10/19/2010 05:07 PM, Tobias Heer wrote:
> a) In my opinion, there is a good reason why HIP control messages are
> not encrypted by default. I think this design was chosen to support
> on-path elements so that they can understand what's going on. Sending
> HIP control messages over encrypted channel obviously changes this
> property. I think this should be stated somewhere.

OK, I can add a comment about that.

> b) Sending HIP control messages over an encrypted channel makes some
> of the security measures that HIP uses unnecessary. The HMAC might
> still be needed (because ESP without authentication is deemed
> insecure). However, the public-key signature of the update seems
> quite superfluous to me now because it is intended to help on-path
> verification of packets - which the encryption prevents. Maybe the
> draft should comment on this? The update signatures is mandatory
> (according to RFC5201) so it might be an option not to touch it and
> accept the wasted overhead (although I don't fancy that option).

I would prefer not to modify the HIP protocol itself even if some of the 
features would become redundant. The idea of the ESP transport mode(s) 
was to work as a drop-in replacement for the regular (no encryption) 
mode. Regarding the signature, hosts that are on the encrypted path as 
one of the relaying elements (e.g., in a HIP BONE scenario) could still 
use it for verification since they terminate the ESP tunnels and thus 
see the decrypted HIP packets, right?

> c) You discuss host mobility but do not mention multihoming is this
> intended?

I did not see any special behavior that would be needed for the 
multihoming case (beyond what is needed for the mobility cases), but 
you're right that making this more explicit makes sense. I changed the 
"Mobility" section's name into "Mobility and Multihoming" and we can add 
more details there if needed (see next question).

> d) To me it is not entirely clear how mobility or multihoming would
> work with the encrypted channels in place. You describe that it can
> work if it is done before the connection breaks. Would both hosts set
> up new SA pairs / TCP connections for all of their possible address
> pairs in order to do the address verification? If yes, the address
> verification during the update is rather useless for TCP because TCP
> does its own handshake already. If no, how does it work? Am I missing
> the point here?

It seems there could be more details on this. The basic idea was "do as 
you used to do but once you're done (with mobility and/or multihoming 
actions) send HIP messages over the new SA". That is, in the TCP mode 
the TCP connection used for the HIP messages should survive just like 
any other TCP connection and in the ESP mode, once there is a new SA, it 
is used for the messages. So new SA pairs would be set for all pairs (as 
before) and there would be no new TCP connections or handshakes but the 
address verification works as it used to.


Cheers,
Ari