RE: [MEXT] re-direction attack on MCoA

["Benjamin Lim" <[e-mail]>]

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