Re: [MEXT] re-direction attack on MCoA

[Vijay Devarapalli <[e-mail]>]

Hi Benjamin,

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.

I also think we should add an informative reference pointing
to draft-lim-mext-multiple-coa-verify-00 for preventing the
attack.

Vijay

Benjamin Lim wrote:
> Hi, 
> 
> Some points inline to start of discussion.
> 
>> -----Original Message-----
>> From: RYUJI WAKIKAWA [mailto:[e-mail]] 
>> Sent: Monday, January 28, 2008 11:27 AM
>> To: [e-mail]
>> 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
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/mext
>>
> 
> 
> 
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mext


_______________________________________________
MEXT mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mext