Subject: [Mobopts] Review of draft-zhao-mip6-rr-ext-01.txt

From: Christian Vogt <[email-masked]>
Date: Wed, 29 Mar 2006 23:38:46 -0600

Fan -

I reviewed your draft draft-zhao-mip6-rr-ext-01.txt.  Here are some
comments.

Section 4.2:

>                      Then HA establishes a table where
>    home_init_ha_cookie, HoA and home_init_cookie are stored in one entry
>    and home_init_ha_cookie is a primary key.  Please note that HA
>    creates the table entry only after it verifies the received packet
>    from MN, thus it does not risk the Denial-of-Service attack at this
>    stage.  Later, when HA receives the HoT packet that seems like from
>    CN, HA just needs to perform the table lookup operation to verify the
>    cookie.  The management of this table does not result in too much
>    extra cost because HA needs to remember the recent home_init_cookie
>    in the original MIP6 RR test anyway.

RFC3775 does not require the HA to remember the home init cookie.  The
home init cookie in Home Test message received from a CN is checked by
the MN only.

>                                          However if HA still concerns
>    about the memory cost, HA can generate home_init_ha_cookie by
>    AES(Kha, HoA | home_init_cookie) and only need to remember 1)
>    home_init_ha_cookie or 2) the output of a hash function over
>    home_init_ha_cookie or 3) even nothing.

I don't think storage would be a problem.  The HA has a Binding Cache
and an IPsec security context for the MN anyway.  Also, as you say, a
Home Test Init message cannot be spoofed due to the MN-HA tunnel.  So
the memory requirement per MN is constant.

Section 4.3:

Given that the CN does not send the home keygen token to the MN's home
address (but to the HA's address), how can the CN know that the MN is
reachable at the home address?

It seems that an attacker could send a HoTI message from an arbitrary
address A, claiming that A be its HA's address.  The attacker would
generate the HV in the HoTI message based on the home address that it
intends to hijack.  The attacker would then receive a home keygen token
which allows it to authenticate a BU on behalf of the true owner of the
home address.

Your could mitigate the attack to some extent by including the prefix of
the HA's address in the home keygen token, and by having the CN check
whether that prefix equals the home-address prefix.  This would at least
verify the reachability of the home-address prefix.  But you would still
not verify reachability at the home address itself.

Section 4.4 and 4.5:

You are proposing a hash chain that can be used to extend the lifetime
of a MN's binding at a CN.  The approach you are suggesting is in fact
similar to the one described in [1], so you may want to include a
reference in the Related Work section and spend some words on the pros
and cons of either approach.

[1] draft-arkko-mipv6-binding-lifetime-extension-00.txt

BTW, the approach in [1] has the advantage that the MN must not
pre-compute a hash chain.  Instead, the MN can just hash a value
obtained during the previous correspondent registration with a value
obtained during the current registration.

Section 4.4:

>    The original MIP6 RR test allows an attacker to intercept the traffic
>    even though this attacker is only able to eavesdrop the traffic in
>    the IPv6 network, which makes the MIP6 network slightly less secure
>    than the IPv6 network. 

You should probably say that, for this to happen, the attacker would
have to be located on the path between the home address and the CN.
Elsewhere, the attacker cannot get hold of the home keygen token that it
would need for such an attack.

>        3.  If seqÆ < seq and h_seqÆ <> H(h_seq)^(seq-seqÆ), CN realizes
>            that there is an attacker that can successfully finish the
>            extended RR test; however, CN is not sure whether this BU
>            message is from the attacker or a valid MN based on its
>            current knowledge.  Thus CN disables this entry, indicates
>            the reason in the BA message and forwards the data packets to
>            the home address.  CNÆs policy may decide to accept the new
>            BU message for this HoA when the current session with this
>            HoA is ended or after a certain amount of time.

Note that the MN may crash and reboot, in which case the MN and the CN
would get out of sync with respect to the current h_seq.  If the CN
blocks the HoA for a while, as you suggest above, you prevent such a MN
from starting over with a new hash chain.

>    The hash chain information should not be lost due to the reboot in CN
>    and MN.  While it is not a big problem for CN as it is just a fresh
>    start, it is better for MN to store the hash chain information in the
>    hard disk so that the synchronization between MN and CN can be
>    restored.

Ah, I see.  But you can eliminate the requirement for stable storage if
the CN does not block the HoA in the described case.

Ok, that's it.

Regards,
- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

_______________________________________________
Mobopts mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mobopts