Re: Comments on draft-ietf-mobileip-mipv6-ha-ipsec-04.txt

[Bernard Aboba <aboba@internaut.com>]

> Actually, its both the RR messages and the payload messages. The main issue
> is therefore the encapsulation format for IP traffic tunneled through the
> home agent.

Ah, this is the real issue, isn't it. Putting a HAO on the tunneled
HOTI/HOT packets isn't a big deal, but putting it on *data* is an issue
for realtime traffic. If *all* the IPsec SAs don't originate
from the HoA, then nothing is gained. Still, this is probably grounds for
a SHOULD but maybe not a MUST (particularly given some security
implications).

>       to update the destination gw address for the outgoing SA at the
>       home agent side.

RR security is weaker than that provided by IKE, so that movement is
potentially a weak link enabling the movement of IPsec SAs under the
guidance of an attacker. It would be different if the RRs were
cryptographically protected, since then we could require that this level
of protection (e.g. RSA key size) were equivalent to that used in IKE.

At a minimum, I think it's probably a sensible thing to provide advice
about restricting the scope of APIs provided to manipulate the MN-HA SAs.
For example, one could require that:

a. The APIs only work when referring to SAs affected by a previously received
   binding update
b. Only cover the SAs described in your document (transport mode MH
   coverage, tunneling HOT/HOTI, etc.)