I tend to agree with Raj that this does not seem a
MIP6-specific issue or at least it does not require any
MIP6-specific solution.
While the way of creating the routing loop is specific to
MIP6, in the sense that MIP6 signaling is used, the outcome
of the attack may be just a flood of packets to the HA. How
is this flooding of packets different from any other
DoS/flooding? Does the HA anyway be equipped to drop packets
in case of packets floods?
The HA may just drop packets if they exceed a ceratin
threshold and optionally delete the binding. This seems to be
enough in my view considering that there is anyway a long
trust relationship between the attacker (i.e. the MN) and the HA.
What do you think?
Gerardo
________________________________________
From: mext-bounces at ietf.org [mext-bounces at ietf.org] On Behalf
Of Vijay Devarapalli [vijay at wichorus.com]
Sent: Friday, October 31, 2008 4:15 PM
To: Charles E. Perkins; Benjamin Lim
Cc: mext at ietf.org
Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can
cause routing loop between home agents
Hi Charlie,
-----Original Message-----
From: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] On
Behalf Of Charles E. Perkins
Sent: Thursday, October 02, 2008 4:51 PM
To: Benjamin Lim
Cc: mext at ietf.org
Subject: [MEXT] Issue #17: Multi-homed mobile node can cause
routing loop between home agents
Hello Benjamin,
I have not seen any further discussion about this issue,
but I agree that the problem does exist.
It might be possible to specify that the Home Agent should (or,
?may?) use the RFC 2473 "Tunnel Encapsulation Limit Option".
to help avert the threat. Otherwise, the loop could persist for
an annoyingly long amount of time. It is also possible for the
home agent to enforce a policy by which a home address on
a network cannot be bound to a care-of address on the same
network, but in fact there may be cases where that would be
a valid binding.
I hope that other people in the working group will
express an opinion about this. At minimum, we could
certainly include text within the Security Considerations
section.
Recommending the use of the Tunnel Encapsulation Limit Option" in the
security considerations section seems to be the best option
to me. Here
is some text.
A malicious mobile node associated to multiple home agents could
create a routing loop amongst the home agents. This can be
achieved when a mobile node binds one home address located on a
first home agent to another home address on a second home agent.
This type of binding will force the home agents to route the same
packet among each other without knowledge that a routing loop has
been created. To present this routing loop, it is recommended for
the home agents to use the Tunnel Encapsulation Limit Option
[RFC 2473], when tunneling packets for the mobile node.
It would be good to recommend a default value for the "Tun Encap Lim"
field, but I don't know what to recommend. How about '5'?
This should be
sufficient for any additional GTP, PMIPv6, HMIPv6 or FMIPv6 tunneling
between the home agent and the mobile node. :)
Vijay
The existing discussion is documented at the following URL:
http://trac.tools.ietf.org/wg/mext/trac/ticket/17
Regards,
Charlie P.
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext
