Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4

From: Alexandru Petrescu <[email-masked]>
Date: 24 Jan 2002 17:20:40 +0100

Hi Pekka,

Pekka Nikander <[email-masked]> writes:
> You physically go to your target network (or tap to a link in
> between), plug in your laptop, pretend to be your own HA, establish
> a binding at the CN, go away, and later let the binding to expire.
> If you have active communications going on when the binding expires
> (e.g. a large file transfer), the packets start bombing to your
> target, and you can even keep the TCP transfer to go on for some
> time by carefully sending false ACKs.

This looks indeed like a feasible attack.  However this is hardly
feasible if CN is required to drop bindings when receiving two
differing BKE's (sorry I use BAKE terminology only because it's easier
for me to put names on messages).

One more thing, what is the fear of the above attack?  That the target
network gets bombed or that it's difficult to identify who provoked
it?  In the first case, you can always bomb something, no feasible
defense at protocol level.  Add new messages to secure something and
then the new entities can be bombed.  In the second case, err, I don't
know, probably this kind of impersonation is a fact of life today,
with faked source addresses in ICMP echo requests.  I guess people
find the true identities by verbal coordination, looking at log
messages, etc.

Please do not get me wrong, I'm not saying there's no need of
protection in Mobile IPv6, just trying to identify what is genuinely
new security flaw introduced by it.

Alex

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 06 Jan 2002 15:30:00 +0200

Erik, Hesham and others,

On the question of whether RR alone could provide security
that is in par with IPv4 security, I think I have came up
with an attack scenario that RR alone does not block (see
below).  However, this attack is certainly fairly far fetched,
and I _personally_ could imagine that being vulnerable to
this one _might_ be acceptable.

The attack scenario:

Let us consider an attacker A, a corrensponding node CN, and
a pre-selected mobile node MN whose home address is HoA.
Now, A has decided to steal all traffic that CN will
initiate towards MN.  To do so, it somehow arranges itself
_once_ to the path between CN and MN's HA.  It may do this,
for example, by visiting the network where CN is located,
where MN's HA is located, or any network in between.

While being at the path between CN and MN's HA, the attacker
creates a binding (and a corresponding BSA) at CN.  This will
succeed, since A knows MN's home address and it can foil the
RR test.  As a result, CN believes that MN is currently located
at the adddress given by A, and therefor whenever it sends
packets to MN, it will send them to the attacker.  Thus, A
is able to steal all connections initiated by CN towards MN.
Furthermore, if CN does not check the return routability
of the MN's home address if there is already an existing BSA,
then the attacker can keep up the faulty binding as long as it
wishes, simply by renewing the binding and BSA periodically.
To renew, it no longer needs to be at the path between the CN
and the MN's HA.

Discussion:

This attack is not present in IPv4 since in this scenario the
attacker steals all traffic _beforehand_, and does not need to
be on the vulnerable path later when the communication session
is actually initiated.  Thus, there is a potential class of
attackers that may be able to launch this attack but that could
not attack under the current IPv4 architecture.

This attack is most effective if the discussed MN is not
actually a mobile node but a stationary node.  In that case
the node will never send binding updates or home address options.
As a result, the attacker may be able to renew the faulty
binding and BSA for long times.  Furthermore, even if the node
initiates a connection, the CN will send replies to the
attacker, allowing the attacker to spy or DoS this connection
as well.  Still further, if the attacker performs the same
attack against both parties, it may establish itself as full
MitM for all future communications between the parties.

In a way, this is a variant of the "future attack" that I
described at the 50th IETF SAAG meeting, see
http://www.tml.hut.fi/~pnr/presentations/IETF50-SAAG-AddrOwn-Slides.pdf

If we consider stationary nodes communicating with CNs,
i.e. about generic non-mobile-ipv6 traffic, this attack
appears to be most devious.  Since the nodes do not assume
their peer to have a binding for them, they have hard time in
determining that there actually is one.  If the attacker is
careful enough, it may get along for long times.  Thus, the
only protection here is that the attacker actually needs _once_
to get access to the vulnerable path between the CN and the HoA.

Let us consider this "_once_ at the vulnerable path requirement."
If all the links involved are physically protected, i.e. if the
links do not accept unauthenticated nodes, the only realistic
threat that I see is the attacker breaking in into _some_other_
computer at one of the links.  For example, if the CN is a web
server at a DMZ, and the DMZ also contains e.g. a poorly administered
Linux-login box, just breaking in to that Linux box could make
it possible to initiate the required faulty bindings at the CN.
As a consequence, once it is found out that the Linux box has
been compromised, the CN must be cleared of any bindings, just
to be sure.

Whether this risk is considered large enough to mandate using CGAs,
i.e. potentially IPR protected technology, goes beyond my apprehension.
But I certainly think there seems to be reason to make CGAs a
preferred and recommended practise, and to be recommended that
bindings that have not been protected with CGA should have relatively
short lifetime, and not be renewable without full RR test upon renewal.

--Pekka Nikander

---

From: Alexandru Petrescu <[email-masked]>
Date: 23 Jan 2002 15:03:05 +0100

Alex Petrescu:
> >An attacker on an intermediate router on CN-HA path could add a static
> >host route to MN through an alternate path.  Just add it, save
> >configuration and leave.  Next time packets from CN destined to MN
> >will go on the alternate path, without attacker being there, right?
> 

Jari Arkko <[email-masked]> writes:
> Adding a static host route would require compromised router,
> is this what you were thinking?

Yes, I was thinking about compromised routers (or cutting cables).
This is needed for the future attack to succeed against RR as
described by Pekka.  And if attacker can compromise routers or cut
cables then he can launch a future attack in today's Internet too, by
changing routing tables or putting his own router in between.  Thus RR
is no worse than v4.

> I think a more likely threat model is someone plugging in
> their laptop at an Ethernet somewhere, but not necessarily
> being able to get in to the routers. (Of course it is possible
> to get to the routers as well, just less likely.)

This is indeed a more likely scenario.  But without access to router,
attacker can do less harm and is also in danger of being detected by
its neighbours.  Windows, Solaris and HP-UX already do that, I think.

Besides, I do not think that the future attack against RR as described
by Pekka is feasible only by plugging a laptop and using ND.

Alex