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

From: "Fan Zhao" <[email-masked]>
Date: Thu, 30 Mar 2006 22:21:52 -0800 (PST)

Hi Christian,

Thanks for your review.

> 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.
Right. This extension to MIP6 RR is for location privacy.
draft-zhao-mip6-rr-ext-00 does not include the location privacy
consideration.

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

> 
> 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.
> 
The idea of hiding MNP by hash function is for RRNP (RR test on 
network prefix owned by MR; MR's HoA is still in the home address test.)
in NEMO originally; however at that moment, NEMO WG is not chartered to 
work on the RO solution yet. Thus I transplanted it to MIP6 RR test.
In a later sister draft, draft-zhao-mobopts-rr-ext-00, (maybe I should
rather refer this draft.) I have removed this part already. I am actually 
thinking not to hide HoA on the path of HA_CN as the attacker on this
path can probe HoA and do a lot of attacks already.

> 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. 
It may be for this purpose. But my original motivation is to reduce
the delay and detect the attack.

> 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.
At the moment when we prepare this draft, we do not know BLE yet.
That is why it is not in the related works. I am sure I will add 
it to the next version.

I have sent a seperate email regarding to [1] and the comparisons 
between them. I think the way hash chain is generated and used is
different.

> 
> [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.
My draft just wants to utilize the one-way property of hash function.
Pre-somputing hash chain is a concern, this is the standard method and 
the memory cost is acceptable. Again, the different way to generate and
use hash chain is because of the different purposes in these two drafts.

> 
> 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.
OK to reword this sentence.

> 
> >        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.
Maybe it is from an attacker. But CN does not block HoA persistently.

Thanks.

Sincerely,
fan

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

---

From: Christian Vogt <[email-masked]>
Date: Fri, 31 Mar 2006 00:48:29 -0600

Hi Fan.

> network prefix owned by MR; MR's HoA is still in the home address
> test.) in NEMO originally; however at that moment, NEMO WG is not
> chartered to work on the RO solution yet. Thus I transplanted it to
> MIP6 RR test. In a later sister draft, draft-zhao-mobopts-rr-ext-00,
> (maybe I should rather refer this draft.) I have removed this part
> already. I am actually thinking not to hide HoA on the path of HA_CN
> as the attacker on this path can probe HoA and do a lot of attacks
> already.

Yes, I think that would be better.

Agree with the rest.

Regards,
- Christian

Fan Zhao wrote:
>>> Then HA establishes a table where home_init_ha_cookie, HoA and
>>> home_init_cookie are stored in one
>> 
>> entry
>> 
>>> 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
>> 
>>>  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.
> 
> OK.
> 
> 
>> 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.
>> 
> 
> network prefix owned by MR; MR's HoA is still in the home address
> test.) in NEMO originally; however at that moment, NEMO WG is not
> chartered to work on the RO solution yet. Thus I transplanted it to
> MIP6 RR test. In a later sister draft, draft-zhao-mobopts-rr-ext-00,
> (maybe I should rather refer this draft.) I have removed this part
> already. I am actually thinking not to hide HoA on the path of HA_CN
> as the attacker on this path can probe HoA and do a lot of attacks
> already.
> 
> 
>> 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.
> 
> That is why it is not in the related works. I am sure I will add it
> to the next version.
> 
>> obtained during the previous correspondent registration with a
>> value obtained during the current registration.
> 
>  Pre-somputing hash chain is a concern, this is the standard method
> and the memory cost is acceptable. Again, the different way to
> generate and use hash chain is because of the different purposes in
> these two drafts.
> 
> 
>> Section 4.4:
>> 
>> 
>>> 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.
> 
>>> 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.
>> 
>> 
>>> 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
>> 
>> Ah, I see.  But you can eliminate the requirement for stable
>> storage if the CN does not block the HoA in the described case.
> 
> Sincerely, fan
>> Regards, - Christian
>> -- Christian Vogt, Institute of Telematics, University of Karlsruhe