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: "Souhwan Jung" <[email-masked]>
Date: Sat, 22 Nov 2003 08:33:15 +0900

Hi Vijay,

You are right. I made a mistake in distinguishing the format of the incoming packet into MR from the format of outgoing packet from MR. But, the attack still works. Please see the inline.

> unprotected binding updates.

In fact, the packet from attacker should has a src=HoA of MR, and dst=HA. 
Then the packet is matched against the IPsec SPD OUT, and MR will apply IPsec.
Finally, MR will generate the packet of src=CoA, dst=HA, and home address option=HoA. Please see the section 6.1 of the same draft http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-06.txt.

> and then of course there is ingress filtering. if the MR does ingress

I already pointed out this in the slide.

> threat 2, slide 4

The packet from attacker should include inner src=HoA of MR.
Then the rest part of the attack scenario works the same as the threat 1.

> done today when you decapsulate a packet and forward the inner

I also pointed out this in the slide. This should be the right way of implementation, and we wanted to point out that the right order of decapsulation-and-then-ingress filtering is important to prevent this type of attack. The implementation of reversed order will cause the problem.

> threat 3, slide 6

I don't believe the check at HA will prevent this attack. The spoofed IP address could be out of the same MNP owned by MR. Then it will get through the ingress filtering at MR. The check at HA also cannot filter the attack packets because the outer and inner src addresses exactly matche the check conditions. (outer src=CoA of MR, inner src = one of MNP owned by MR)

Comments?
Thanks.

Souhwan

---

From: "Souhwan Jung" <[email-masked]>
Date: Sat, 22 Nov 2003 08:33:15 +0900

Hi Vijay,

Comments?
Thanks.

Souhwan

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 21 Nov 2003 16:03:52 -0800

Souhwan Jung wrote:
> Hi Vijay,
> 
> You are right. I made a mistake in distinguishing the format of the 
 > incoming packet into MR from the format of outgoing packet from MR.
 > But, the attack still works. Please see the inline.
> 
> 
>>section 5.2.1 of 

right.

> I already pointed out this in the slide.

right. ingress filtering at the MR is the only solution to this.
infact the MR should make sure that the MNN is not using MR's
HoA to send any packet. I will add some text to the Security
Considerations section.

> I also pointed out this in the slide. This should be the right 
 > way of implementation, and we wanted to point out that the right
 > order of decapsulation-and-then-ingress filtering is important to
 > prevent this type of attack. The implementation of reversed order
 > will cause the problem.

okay. I will add some text warning against this threat.

> I don't believe the check at HA will prevent this attack. The spoofed 
 > IP address could be out of the same MNP owned by MR.

if the address is from the MNP and the MNN is inside the Mobile
Network, why would you call the address a spoofed address? it
is a valid address as far as ingress filtering is concerned. also
it is a topologically correct address with respect to the prefix
being advertised in the Mobile Network.

> Then it will get 
 > through the ingress filtering at MR. The check at HA also cannot
 > filter the attack packets because the outer and inner src addresses
 > exactly matche the check conditions. (outer src=CoA of MR, inner src =
 > one of MNP owned by MR)

so how this threat differnt from the current situation on the
internet. I can launch DoS attacks today from a fixed ethernet.
my default router does not have to be a mobile router. NEMO does
not introduce this threat, right?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 21 Nov 2003 16:03:52 -0800

right.

Vijay

---

From: "Souhwan Jung" <[email-masked]>
Date: Sat, 22 Nov 2003 09:54:10 +0900

> Vijay Devarapalli wrote:

> being advertised in the Mobile Network.

It could be a spoofed IP address in terms that the attacker is using the IP address of another MNN inside.

> not introduce this threat, right?

Sure. The inside attacker in current Internet can do launch this attack. 
But the problem is that the attacker can launch this attack from outside, too if the ingress filtering at the access router of the attacker is not activated. To my knowledge, most routers just turn off the ingress filtering because of their concern in performance. Then, the heavy usage of IP-in-IP tunnel in MR and HA can make this problem serious, because the attackers from outside can generate a bunch of IP-in-IP packets and send them to HA directly.
If IP-in-IP tunnel packets between MR and HA are secured using IPsec ESP, then HA can just drop the packets from outside, but applying IPsec to all the packets through the IP-in-IP tunnel could cause a heavy load to the MR.
 I believe that a simple authentication mechanism for filtering packets at MR and HA may be recommended.

Souhwan

---

From: "Souhwan Jung" <[email-masked]>
Date: Sat, 22 Nov 2003 09:54:10 +0900

Souhwan

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 21 Nov 2003 17:15:01 -0800

Souhwan Jung wrote:
> It could be a spoofed IP address in terms that the attacker is 
>using the IP address of another MNN inside.

you cant prevent this. it is possible today on ethernet, WLAN.
Secure Neighbor Discovery might be able to fix this.

> Sure. The inside attacker in current Internet can do launch 
> this attack. But the problem is that the attacker can launch
> this attack from outside, too if the ingress filtering at the
> access router of the attacker is not activated. To my knowledge,
> most routers just turn off the ingress filtering because of their
> concern in performance. Then, the heavy usage of IP-in-IP tunnel
> in MR and HA can make this problem serious, because the attackers
> from outside can generate a bunch of IP-in-IP packets and send 
> them to HA directly. 
> If IP-in-IP tunnel packets between MR and HA are secured using 
> IPsec ESP, then HA can just drop the packets from outside, but
> applying IPsec to all the packets through the IP-in-IP tunnel
> could cause a heavy load to the MR. 

this threat comes mainly from not using ingress filtering.
there isnt much we can do about it. requiring IPsec protection
for all tunneled traffic between the MR and the HA however is
not a solution, IMO.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 21 Nov 2003 17:15:01 -0800

Vijay

---

From: "T.J. Kniveton" <[email-masked]>
Date: Fri, 21 Nov 2003 19:30:01 -0800

On Nov 21, 2003, at 4:54 PM, Souhwan Jung wrote:

> But the problem is that the attacker can launch this attack from 
> outside, too if the ingress filtering at the access router of the 
> attacker is not activated. To my knowledge, most routers just turn off 
> the ingress filtering because of their concern in performance.

This is wrong implementation. If a router wants to boost performance by 
not checking anything in the packet header, it should keep its 
forwarding path separate from the packet generation path where it might 
apply IPsec SPD rules. If a router is applying IPsec policies to 
packets it is forwarding, that is its own fault, IMO.

> Then, the heavy usage of IP-in-IP tunnel in MR and HA can make this 
> problem serious, because the attackers from outside can generate a 
> bunch of IP-in-IP packets and send them to HA directly.
>
Well as Vijay mentioned, this is easy to prevent -- you simply check 
whether a packet you are forwarding is using your own source address.

Alternatively, when a packet comes on an ingress interface, you can 
mark the buffer with a bit, and then when you do your policy rule 
checking, if the bit is set, you do not apply any IPsec rules to the 
packet - just send it as-is.

> If IP-in-IP tunnel packets between MR and HA are secured using IPsec 
> ESP, then HA can just drop the packets from outside, but applying 
> IPsec to all the packets through the IP-in-IP tunnel could cause a 
> heavy load to the MR.

Well, when the packets are decapsulated, the MR doesn't necessarily 
know they came from a tunnel. But the above rule will still apply.

> packets at MR and HA may be recommended.

And what would the authentication mechanism be? Doesn't the 
authentication depend on how access control is administered at the MR's 
and HA's networks?

TJ

---

From: "T.J. Kniveton" <[email-masked]>
Date: Fri, 21 Nov 2003 19:30:01 -0800

TJ