[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Bernard Aboba wrote:
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. 
Right.


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

Yes, but if you look at the way the requirement in 3.2 is formulated
it says that you MUST _support_ this particular set of headers. The
intention is that folks are free to support other encodings as well.
Would this be sufficient to you?


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

Something like this could be good yes. One thing to note is that the
IKE-MIPv6 API is *only* for the home agent case. And all location
updates by the home agent are due to cryptographically protected
Binding Updates. So I don't think RR security level will make IPsec
SAs vulnerable to attacks. But yes, this probably deserves to be
explained in the document ;-)

Jari