Re: [MEXT] re-direction attack on MCoA

["George Tsirtsis" <[e-mail]>]

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 <[e-mail]> 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:[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
>

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