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

[Bernard Aboba <aboba@internaut.com>]

> Some background info.
> The HOTI messages are reverse tunneled through the HA with an outer
> source address = CoA and an inner source address = HoA. The MN needs to
> send a binding update to the HA before it can send HOTI messages to
> correspondents so that the HA can check the HoA/CoA relationship in the
> reverse tunneled packets. (If HOTI was sent with CoA as the source the
> response=HOT would go directly to the CoA i.e. it would fail to test
> that the MN is indeed reachable at its Home Address.)

Since the HA decapsulates the tunneled HOTI message from the MN, it
reaches the CN with source address = HoA. This is true regardless of the outer
source address of the packet tunneled to the HA by the MN; the presence of
a HAO in the outer IP header makes no difference. Regardless, the HOT
message sent by the CN has destination address = HoA; as a result, the
packet is received by the HA. The proof of reachability is that the HA
routes the HOT to the MN by some means. The outer destination address of
the HOT sent by the HA to the MN  = CoA because that is the only way for
the HA to reach the MN when it is not at home; whether the HOT is
encapsulated in an IP packet with inner destination address = HoA or
instead, a RH Type 2 header is used doesn't make a difference.

So it seems like the reachability test is met either way, no?

> >  At a minimum, I'd
> > like to understand why the HOTI/HOT messages can't have an HAO even if
> > HOTI/HOT is done prior to movement.
>
> A HAO on the HOTI would cause the CN to reject the HOTI after movement
> since the HoA/CoA wouldn't match the binding cache on the CN.

Since the HAO is only on the outer IP header which is decapsulated by the
HA, the CN never sees this; it only sees the contents of the decapsulated
HOTI message and the COTI as well. So the HOTI would not be rejected by
the CN.

I think the issue is actually more related to the checks done by the HA on
the HOTI/HOT and COTI/COT messages. As you said, the MN-HA BU must be done
first to create the binding cache entry. However in looking through both
this draft and draft-ietf-mobileip-ipv6-21.txt I am not finding a section
describing the checks done by the HA. For example, these checks are not
described in Section 8.4.

Note that Section 11.6.1 of the MIPv6 draft indicates that a HOT tokens
MAY be reused, so that HOTI/HOT messages don't need to be sent after every
move.