Subject: [nemo] tunneling threats

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Nov 2003 15:39:42 -0800

hi all,

Souhwan Jung presented some possible threats related to tunneling
and MNN spoofing addresses. his presentation is at
http://www.mobilenetworks.org/nemo/ietf58/slides/nemo-ietf58-threat-analysis.ppt
(there is a pdf file of these slides at
http://people.nokia.net/vijayd/nemo/nemo-ietf58-threat-analysis.pdf)

I am trying to see if anything needs to be fixed for the Basic
Support protocol to prevent these threats.

threat 1, slide 3
-----------------

a MNN uses the CoA of the mobile router and sends a BU to the
Home Agent. when the MR receives the BU, it realizes it has to
forward the packet to the HA. Souhwan claimed that the IPsec
SA used for protecting the Binding Update between MR and HA will
get applied to this packet.

what is missing in this slide is that we dont know if the MNN
included a Home Address Option or not and if it did, what the
contents of the Home Address Option are.

so there are three cases.

a. MNN did not include a Home Address Option
b. MNN included a Home Address Option with address set to MR_HoA
c. MNN included a Home Address Option with address set to some
    other address

(a) is not a valid Binding Update and will be dropped immediately.

section 5.2.1 of 
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-06.txt
describes the SPD entries on the mobile node/mobile router for
protecting Binding Updates.

      mobile node SPD OUT:
        - IF source = home_address_1 & destination = home_agent_1 &
             proto = MH
          THEN USE SA SA1

the source address on the IPv6 header is not the home address
of the MR when the MR attempts to forward the packet received
from the MNN. so the SA for protecting the BU between MR and HA
will be not be selected for protecting the packet. infact there
wont be any SPD entry for source=MR_CoA, dst=HA, protocol=mobility.
so the BU is forwarded unprotected. the Home Agent drops
unprotected binding updates.

and then ofcourse there is ingress filtering. if the MR does ingress
filtering, it should drop the packet when it realises that an MNN is
sending the packet with MR's CoA as the source address.

threat 2, slide 4
-----------------

in this scenario, the MNN sends a Binding Update using IP-in-IP
tunneling.

once the packet is decapsulated at the MR, it looks exactly like
the packet in threat 1. there is no problem again, because there
is no corresponding SPD entry.

and then there is another check that the Mobile Router can perform.
whenever it decapsulates a packet and forwards the inner packet,
it *must* verify if the source address on the inner header is valid.
the decapsulated packet will fail this check because the source
address on the inner header is the CoA of the MR. such checks were
done today when you decapsulate a packet and forward the inner
packet.

and the claim in the slide "At this point, MR cannot tell the fake
BU from a BU from itself, and applies IPsec ESP" is not valid.

threat 3, slide 6
-----------------

in this scenario, MNN generates an IP packet with the source
address set to a spoofed IP address, which does not belong
to the Mobile Network.

section 8 of the Basic Support draft says

>    The Home Agent has to verify that packets received through the
>    bi-directional tunnel belong to the Mobile Network.  This check is
>    necessary in order to prevent nodes from using the Home Agent to
>    launch attacks that would have otherwise been prevented by ingress
>    filtering.  The source address of the outer IPv6 header MUST be set
>    to the Mobile Router's current Care-of address.  The source address
>    of the inner IPv6 header MUST belong to the Mobile Network Prefix
>    owned by the Mobile Router.

this check at the HA should prevent this threat. also if the
MR performs ingress filtering, the packet will get dropped
at the MR itself.

Souhwan, if I misunderstood the threats, let me know.

if folks are interested, there is a very long discussion of
something similar at
http://users.piuha.net/jarkko/publications/mipv6/issues/issue319.txt

comments?

Vijay

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 24 Nov 2003 10:06:17 -0000

Hi:

I have in mind that the RO in the nested structure can help on such
problems. Maybe we can think of it at the time we write the problem
statement?

It seems important to be able to prevent untrusted (anonymous) visitors
from sending packets over the reverse tunnel. For the Home security, for
the privacy of the visitor, you name it. This means that visitors would
have to manage their ROed mobility regardless of the mobility of their
attachment router.

An example of this is a mobile router with an interface that's open to
anonymous visitors. On that interface, the MNP is not advertised. The
advertised prefix is either a locally delegated prefix or a scoped
prefix. Packets from that interface are not tunneled over the MRHA but
can only be forwarded somehow to the TLMR. And RO provides the means for
the TLMR to forward the packets back to that prefix.

That model can for instance be applied easily to the source routing
based RO used in RRH. MRs can forge and renew regularly the prefixes
they expose on the open interfaces. Only the MR that stamps a RRH entry
actually uses that information on the way back, so the advertised prefix
is forged and used locally. Packets from anonymous visitors that have an
RRH are naturally forwarded to the TLMR (this is plain RRH forwarding).
Packets from anonymous visitors with no RRH are dropped by policy. Since
the forged prefix can be crypto'ed, there's a way for the MR to check
for RRH attacks. Renewing an advertised forged prefix is analogous to a
movement for the anonymous visitors. Additionally, this protects the
privacy of the visited router...

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 24 Nov 2003 10:06:17 -0000

Hi:

Pascal