Subject: Re: [MEXT] re-direction attack on MCoA

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 1 Feb 2008 19:35:35 +0900

George,

Thanks for summary.
I agree this issue is not specific to MCoA.

>  In fact I think the following should
> be removed form the MCoA draft.....possibly moved to the flow
> filtering draft.:
> "   This valid care-of address could then be used by the malicious  
> mobile
>   node to set up flow filtering rules at its home agent, thereby
>   controlling and/or launching new re-direction attacks."

OK

regards,
ryuji

On 2008/01/29, at 19:58, George Tsirtsis wrote:

> Hi Ben, et.al.,
>
> While the issue you point out is real (everyone seems to agree with
> that) it falls under the category of traceable attacks, as others have
> already pointed out. In MIPv6 we never really considered the issue of
> a "fake" CoAs as a very important one (Only MIPv4 FA Mode deals with
> that). Indeed, several attacks, like the redirection attack you point
> out are possible, even without MCoA support. But other attacks are
> also possible without MCoA support e.g., an MN associates with two
> different HAs and registers the HoA from the first as the CoA for the
> second and vice versa, creating a routing loop.
>
> So, I share the sentiment of the group that mitigation techniques
> should be defined outside the MCoA spec, and I would suggest we
> actually expand the scope of these techniques to cover also other
> cases involving CoA based attacks.
>
> In any case the attack you describe for the MCoA case does not become
> really interesting unless it is combined with flow filtering which is
> out of scope of the MCoA draft. In fact I think the following should
> be removed form the MCoA draft.....possibly moved to the flow
> filtering draft.:
> "   This valid care-of address could then be used by the malicious  
> mobile
>   node to set up flow filtering rules at its home agent, thereby
>   controlling and/or launching new re-direction attacks."
>
> Regards
> George
>
> On Jan 29, 2008 3:03 AM, Benjamin Lim  
> <[email-masked]> wrote:
>> Hi Vijay,
>>
>> =8==8<=8==
>>> FWIW, for the current draft, I think it is sufficient to
>>> point out the threats in the security considerations section.
>>> The home agent knows which mobile node launched the attch, so
>>> that should be a deterrent. We should not require the CoA to
>>> be a CGA, require CBA or mandate a return routability test
>>> for the CoA for the multiple CoA extension.
>> [Ben] I am not mandating a solution for CoA testing yet. My  
>> intention in my
>> draft was to analyze and discuss the best way to solve the problem.  
>> Till
>> then, I feel it might be better to list the current possible  
>> approaches to
>> the problem in the MCoA draft. These approaches serves as some  
>> options that
>> implementers can take to help advert such problem.
>>
>>>
>>> I also think we should add an informative reference pointing
>>> to draft-lim-mext-multiple-coa-verify-00 for preventing the attack.
>> [Ben] A standard track document pointing to a draft that may expire  
>> for
>> solutions. I am not sure if this is the correct way to go.
>>
>> Regards,
>> Benjamin Lim
>>
>>
>>>
>>> Vijay
>>>
>>> Benjamin Lim wrote:
>>>> Hi,
>>>>
>>>> Some points inline to start of discussion.
>>>>
>>>>> -----Original Message-----
>>>>> From: RYUJI WAKIKAWA [mailto:[email-masked]]
>>>>> Sent: Monday, January 28, 2008 11:27 AM
>>>>> To: [email-masked]
>>>>> Subject: [MEXT] re-direction attack on MCoA
>>>>>
>>>>> Hi,
>>>>>
>>>>> At the last IETF meeting, Benjamin presented the security
>>>>> vulnerability of MCoA, re-direction attack.
>>>>> Benjamin's text is merged into the security consideration
>>> section.
>>>>> Thanks Benjamin.
>>>>>
>>>>> However, we didn't merge the solution part in the MCoA.
>>>>> The proposed solution is more like an extension and should
>>> be written
>>>>> in the separate document.
>>>>> We believe the issue of re-direction attack should not be often
>>>>> happened because a malicious mobile node is always traceable by an
>>>>> operator (i.e. HA).
>>>>> A mobile node must take certain risk to do re-direction attack.
>>>> [Ben] Such risk taken by the mobile node does factor into
>>> the account
>>>> on wether the attack will occur. However, I find it hard to justify
>>>> that such risk will prevent such attack from happening
>>> often. If more
>>>> and more attackers are willingly to take such risk (e.g.
>>> strong sense
>>>> of purpose or even 'big ego') or there exisit better mechnisam that
>>>> helps mask the attacker identity in the future, can we say
>>> that such
>>>> attacks will not happen often?
>>>>
>>>>> For the MCoA document it should be sufficient to just
>>> point out this
>>>>> threats.
>>>> [Ben] This is my point of view. As this is a standard
>>> tracks document
>>>> for a protocol, stating a possible miuse of the protocol (aka loop
>>>> hole) without providing some soultions or guideline to it
>>> seems funny.
>>>> Its like saying "hey you can exploit this protocol this way. How to
>>>> slove/prevent it, crack your own brains" Hence, my intention of the
>>>> below proposed text is to serve as a guide that such exploit can be
>>>> reduce/prevent with some methods. This I feel helps
>>> implementers as we
>>>> provide some basic steps to help advert such misuse.
>>>>
>>>> Would appericate any comments to help in this discussion. Thanks!
>>>>
>>>> Regards,
>>>> Benjamin Lim
>>>>> If you have any comments, let us know.
>>>>> I attach the Benjamin's proposed text.
>>>>>
>>>>> thanks
>>>>> ryuji
>>>>>
>>>>>
>>>>>
>>>>> To mitigate such risk described in Section 9, one approach
>>> is for the
>>>>> care-of address to be secured cryptographically (CGA) [RFC-3972],
>>>>> thus permitting the home agent to know if the mobile node actually
>>>>> owns that particular care-of address listed in the binding update
>>>>> message.
>>>>> However,
>>>>> introducing cryptographically generated care-of addresses might
>>>>> increase the complexity of the mechanism to achieve
>>> multiple bindings
>>>>> such as how a message can contain multiple CGA signatures
>>> for each of
>>>>> the care-of addresses, integration between the CGA module and
>>>>> Mobility Support module in a network stack implementation
>>> and further
>>>>> increasing the size of the binding update message.
>>> Furthermore, using
>>>>> CGA does not prevent a malicious mobile node to launch a flooding
>>>>> attack against a subnet by generating multiple
>>> non-existent care-of
>>>>> addresses in that subnet using the mobile node's own public keys.
>>>>>
>>>>> Another approach to mitigate the risk is to employ some means at a
>>>>> home agent to limit the amount of information that a home
>>> agent can
>>>>> send to a care-of address that has not be tested for its
>>>>> reachability. This reduces the chances of the home agent from
>>>>> flooding packets to a particular untested care-of address.
>>> A possible
>>>>> technique to achieve this is to use credit- based
>>> authorization (CBA)
>>>>> [RFC-4866]. In this technique, for the home agent to fully use the
>>>>> care-of address for packet routing, the home agent would need to
>>>>> receive a packet from the mobile node from the untested care-of
>>>>> address.
>>>>> However, the packets that the home agent receives from
>>> these untested
>>>>> care-of addresses might not be sent by the mobile node.
>>> Hence, this
>>>>> technique and the following few proposed techniques will
>>> henceforth
>>>>> assumes that ingress filtering within the network is done. For
>>>>> example, a mobile node can use the Internet Control
>>> Message Protocol
>>>>> (ICMP) described in [RFC-792] to send a request message
>>> via its home
>>>>> address to a untested victim care-of address, thereby triggering a
>>>>> response from this care-of address. Also, in situations where an
>>>>> interface of the mobile node has asymmetrical link characteristics
>>>>> (e.g. General Packet Radio System), that particular
>>> interface might
>>>>> have resource constraint on its upload path making it costly for a
>>>>> mobile node to send a packet to its home agent using that
>>> particular
>>>>> interface.
>>>>>
>>>>> In yet another approach, instead of the home agent waiting for a
>>>>> packet to fully utilize a care-of address for routing, it might be
>>>>> possible for the home agent to send a packet to a untested care-of
>>>>> address to trigger a response from the mobile node from
>>> that care-of
>>>>> address. One technique described in [ID-RRCOOKIE] uses a cookie to
>>>>> prove to the home agent that the mobile node is reachable at a
>>>>> specified care-of address. Another technique could employ
>>> the use of
>>>>> the Binding Refresh Request message to trigger the mobile node to
>>>>> send a binding update message from that care-of address to
>>> the mobile
>>>>> node. However, this technique of testing reduces the optimization
>>>>> benefit of sending bulk registration as it would require
>>> the mobile
>>>>> node to respond via all these care-of addresses. In this case, the
>>>>> mobile node might as well send the binding update message
>>>>> individually for each care-of address.
>>>>>
>>>>> To optimize the previous approach in order to keep the benefits of
>>>>> bulk registration, the home agent could test the care-of
>>> address by
>>>>> asking a mobile node to reply from a different care-of address as
>>>>> oppose to the care-of address that was used by the home
>>> agent to send
>>>>> the trigger message.
>>>>> This utilizes the concept of multiple care-of addresses
>>> whereby the
>>>>> mobile node need not respond back using the same path as the
>>>>> reception of the request. Such a concept is particularly useful in
>>>>> the event that the mobile node has several unverified care-of
>>>>> addresses that needs to be tested.
>>>>> By
>>>>> asking the mobile node to respond via another care-of
>>> address, in one
>>>>> round trip time, the home agent would be able to verify
>>> two care-of
>>>>> addresses.
>>>>>
>>>>> _______________________________________________
>>>>> MEXT mailing list
>>>>> [email-masked]
>>>>> https://www1.ietf.org/mailman/listinfo/mext
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MEXT mailing list
>>>> [email-masked]
>>>> https://www1.ietf.org/mailman/listinfo/mext
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> MEXT mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/mext
>>
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mext