Subject: [mobile-ip] Comments on mipv6 threat model

From: Alexandru Petrescu <[email-masked]>
Date: 17 Jul 2001 22:05:15 +0200

Hi,

I have further comments on the mipv6 threat model in
draft-team-mobileip-mipv6-sec-reqts-00.txt.

-there's a text ordering problem at the end of section 6.8 and before
 section 6.8.1: threat H.3 is mentioned twice, once as H.2 and once as
 H.3.
-in the case B (attacker on the same link as MN in a foreign net) an
 attacker can send false negative Binding Acknowledgments to the MN in
 response to legitimate BU's.  Effect: MN keeps sending BU's.

---

From: Alexandru Petrescu <[email-masked]>
Date: 19 Jul 2001 09:26:56 +0200

I shouldn't follow-up to my own posts, and this is long.

The amount of available information to the attacker should somehow be
quantified and/or ordered.  E.g. an attacker has to pay a lesser
dollar price in order to listen to a wireless broadcast media and a
higher dollar price to install himself on the HA subnet.

Each damage (realization of threats) should be quantified and/or
ordered.  E.g. a DoS attack on the MN is undesirable but an MITM is
worse.

A threat model should be more related to a real world environment,
media access type, inter- or intra-operator, how often do handovers
happen.  Something along the lines of an evoluated RFC2005
(Applicability Statement for MIP).

A threat model should refrain from even suggesting solutions, like in
"should be authorized" or "should have an SA".  In the draft, for each
threat, there's scenario, threat, reaction, effect, requirement.  The
requirements should probably be left off.  The "effects" are in fact
"risks" and should be deduced later, not at the same time as building
the threat model.

Location privacy can be violated not only by means of Binding Requests
(threat D.2) but also by means of sending tunnelled packets supposedly
coming from the HA as redirections from a CN not having a binding
cache entry for this MN. (page 98 last paragraph of MIPv6-14).
E.g. an attacker CN builds a tunnelled packet that would come via the
HA from a CN that does not have a binding for the victim MN.  In this
packet the attacker puts its address as the source address in the
inner packet.  I'm wondering if I'm right on this one.

Threat G.1 too much related to B.3.  If I were to exploit "forwarding
from a previous CoA" I would mount the following...  Consider MN1 and
MN2 (MN2 is the victim), attacker AT, oldAR and newAR, TRD is a
tunnelled redirected packet, the sort that the CN sends to an MN
through the HA, for which MN has no entry in binding cache.  Now, MN1
moves from oldAR to newAR.  MN1 establishes binding for CoA at oldAR.
AT sends fake BU to oldAR and removes binding of CoA.  MN2 shows up
under oldAR and obtains CoA.  AT sends TRD to MN1 such that MN1 sends
BU of CoA to CN towards MN1, and not towards the legitimate MN2.  Thus
MN1 "attacks" MN2, all indirectly provoked by AT.

Threat G.1 assumes that AR defends a certain address that is also
defended by MN, on the same link.  What will DAD give?

"Functional requirements"? Like in the following.  If a legitimate MN
knows that it could only send BU's according to the rate limiting
restriction, it has no reason to try to process and respond to an
incoming flood of binding requests.  Thus this kind of particular
flooding (resource exhaustion) threat can be dealt with without
authentication requirements.

Alex