Subject: RE: [mobile-ip] RE: Is RR only enough ?

From: Erik Nordmark <[email-masked]>
Date: Mon, 7 Jan 2002 19:54:23 +0100 (CET)

> 1. You implied that today's MITM attacks (or at 
> least the ones you mentioned in this thread)
> can be avoided be e2e encryption. The attack I'm
> referring to can not be avoided by e2e encryption. 

If e2e security is done right any MiTM attack would just be capable of
performing a DoS attack by preventing communication.
"Done right" assumes that the peers some how know the identity of each
other and the public keys associated with those identities
and that's what is required to be able to securely be able to communicate with
a known entity.

> 2. If I understood you correctly, you were implying
> that the MITM in the scenario you mentioned is 
> intercepting packets. I.e. the MITM has the ability
> to receive the packets, modify them and hence cause
> a situation where both a MN-CN connection 'goes 
> through him'. On the other hand, in the attack I'm 
> referring to, the MITM only needs to 'see' the 
> packets addressed to the Home address of the MN. 
> He doesn't need to intercept any packets.

Yes, there is such a subtle difference.
But Maruc Leech said in the MobileIP meeting in SLC that for on-path
attacks we shouldn't worry about the distiction between an active
and a passive attacker. 
This seem to make sense to me - if somebody uses ARP/ND spoofing to gain access
on multi-access links or hacks a switch/router in the path it would be easy
for them to modify packets.

> So lets consider this scenario:
> 
> - Bad Guy is on the path between the CN and the HA. 
> For simplicity lets assume Bad Guy is on an ethernet. 
> 
> - Bad Guy forms an address based on the RA on that 
>   ethernet. Bad Guy also puts his card in promiscuous
>   mode. 
> 
> - Bad Guy sees one packet addressed to the MN's Home 
>   address. From that he gets the CN's address and 
>   the MN's home address (he could have the home address
>   before anyway, it would be public knowledge). 
> 
> - No Bad Guy can launch this attack regardless of whether
>   e2e security is used between the MN and CN. 

But without binding updates the additional piece that is needed
in today's internet is to spoof the ARP packets for the routers'
and victim's IP addresses and now all packets will go through the attacker.

There is a subtle difference in that an ARP spoofing attack might be more
"visible" than snooping the wire - if an admin happens to look at the
content of the ARP cache during the attack the admin might observe that it
doesn't look like the router's Ethernet address.
But an admin is pretty unlikely to look.

> I don't know how to assess whether an attack is 
> significantly worse than another, perhaps someone
> can point me to some general guidelines, but AFAICS,
> this attack (I mention above) seems to be significantly
> different from the ones existing today.

I agree there are differences but I find them rather subtle.
I don't have a magic way to tell the difference other than by trying to
put myself in the shoes of a determined attacker. If the attacker can get
access to a multi-access link in the path what can be done?
If the attacker can break a switch/router in the path what can be done?

> Just to overload this email a bit, I'd like to suggest
> that IF all agree that this attack is significantly
> different from today's attacks we can choose between
> two options I have in mind:
> 
> - CGAs combined with RR as one obvious option

I agree that CGA+RR is stronger than just RR.
I'm just trying to make sure we all understand what the differences are
in terms of residual attacks.

> - Extending BU3WAY or BUSEC to make them BU4WAY :)
> So in this case the MN would send 'half' the secret
> through the HA, and the other half directly from
> its CoA. The CN would also reply in both paths
> (i.e. one to the Home address and one to the CoA). 

BU4WAY wouldn't address an attacker on the CN's link, right?
I think it is easier to attack at the edges (where there are lots of hosts)
than in the middle of the network. 
And even with BU4WAY an attacker between the CN and HA can just claim to
itself be the CoA, thus it would be on both of the paths.

> One assumption: ingress filtering on source addresses 
> is widely used. 
> 
> Based on this suggestion and the assumption above, 
> the attacker will not be able to use the MN's Home
> address as a source address since the packet will be 
> dropped by ingress filtering. 

If the attacker is on the path between the HA and the CN
it sits on the path where packets normally tracel what have the HoA as a source
thus ingress filtering can't filter those out.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 4 Jan 2002 04:04:14 +0100 (CET)

> I thought we agreed that an man in the middle
> which would need to be part of the network
> (switch/router) was something we could ignore.  As
> in, if that happens, BU hijacking is just one of a
> nearly infinite number of attacks you could mount
> -- most of which have nothing to do with MIP.
> 
> Now, if you can show an attack by an end host in
> the CN's, MN's or anybody else's network which can
> be mounted without requiring a compromised
> router/switch I'll be the first one to change my
> mind on this. One condition here though: if the
> access router/switch can defeat the attack, and
> it's localized to an attack on its networks (eg
> another CN on the same network segment), it's not
> unreasonable to expect that that be part of the
> entire RR solution, IMO.

Mike,

An attacker (e.g. a host) on a multi-access link next to the CN, HA, or MN
can lauch successful attacks against RR in general.
(BU3WAY shows a scheme for preventing attacks on the link attached to the MN
and the rest of the path between the MN and HA.)
This does require that the multi-access link allows anybody to receive
packets (e.g. non-switched Ethernets or 802.11) or using ND/ARP spoofing
to become a MiTM on those links.

But this isn't any worse than IPv4 today either - any host attached e.g. to
a non-switched Ethernet next either of two communicating nodes can use
ARP spoofing and/or snooping packets to become a MiTM for TCP connections
and UDP "sessions".

  Erik