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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 8 Jan 2002 13:41:06 +0100

=> Sure, but it was suggested that TLS or other upper
layer security mechanisms can be used to avoid 
these types of attacks today. I don't think they 
would help avoid this attack using the BU. 

Also, I agree with what you say about security
"Done right", implying the identity exchange between
the two parties, but perhaps we should document
somewhere (in the ultimate solution) that this will
override any other security mechanism for BUs. 
I.e. if there is "proper" SAs already established, 
they should be sufficient for the MN to send 
a BU without the need to run any other mechanism. 

(proper is per the definition you mention above
and/or any other additions deemed necessary)

  > 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 the difference is that the BU attacker
will not have to modify anything, which makes 
him more dangerous if:

1. upper layer security is used (not IPsec)
2. If IPsec is used but the CN still accepts
   RR for BU. (strange situation that we should 
   not allow of course).

I agree with the ARP case, However, ND has the potential
of being secure, but even if it was secured (somehow
keys are distributed), this problem would still exist. 

Of course having secure ND does not imply that no one 
will launch attacks outside the link.

  > 
  > 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.

=> Exactly.

  > But an admin is pretty unlikely to look.

=> I'll take your word for it :), I haven't 
admined before, but I know it's pretty
unlikely for anyone to read ARP caches without
noticing a problem, so I think you're right. 
But as you said above, should a problem be 
noticed, there would be a way to trace it. 

I know the difference is subtle and I'm not trying
to say it's good enough to discredit any mechanisms, 
but I just wanted to bring it up so at least we know
it can exist and be aware of that when deciding
on the  tradeoffs. 

  > 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?

=> I agree. To me it seems easier to be in the path
than be required to compromise a router/switch. 
But as you said you can get the same effect with ARP. 
So we come to two very subtle differences really:

- The BU attacker does not need to modify any information
  in the packet. This makes the attack work if end users 
  were relying on upper layer security (TLS or app). 

- The BU attacker does not disturb any other nodes 
  on link, so it's harder to discover that there is 
  a problem. Basically the only way to locate the 
  attacker is through the CN's Binding Cache or if 
  someone is looking for HAO inside the packets. 
  Both cases are unlikely.

  > 
  > 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.

=> Absolutely, as I said I only wanted to bring it up
   so that we can cover more of the possibilities and 
   hopefully end up with more 'awarness' in our tradeoffs.

  > 
  > BU4WAY wouldn't address an attacker on the CN's link, right?

=> Right.

  > I think it is easier to attack at the edges (where there 
  > are lots of hosts)
  > than in the middle of the network. 

=> Sure, but my understanding was that this is always 
   possible and is not specific to MIPv6.

  > 
  > 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.

=> True, BU4WAY wouldn't help with that.

Hesham

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 8 Jan 2002 21:54:46 +0100 (CET)

>   > 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.
> 

By "these attacks" do you mean the DoS impact of the attacks or the
an attack that can modify the content of the communication?
The DoS attack by a MiTM can never be prevented.
The modification of content can be prevented with TLS, IPsec, etc.

> a BU without the need to run any other mechanism. 

You're skipping a few steps.

If you want to use an existing SA (IPsec, SSL, whatever) to protect BUs
the identities associated with the SA needs to be quite different
than what you'd get for other use of security.
E.g. when using SSL to a website you'd like to know that the identity
is www.example.com; when sending secure email to me you'd like the
identity to be [email-masked], but for a BU the identity you'd need
is the home IP address.

Using security associated with one type of identity for something else
isn't likely to get the security you'd expect.

Thus my personal opinion is that we should make the BU security be independent
of other (content-oriented) security. Thus if folks want to use IPsec or SSL
you'd still use the same BU security mechanism.

> keys are distributed), this problem would still exist. 

ND has the potential to be secure because of the IPsec pixie dust
in the security considerations section??? (Yes, I've learned some things
since that document became a draft standard without anybody having implemented
ND secured by IPsec.)

> it can exist and be aware of that when deciding

We're in agreement that we need to understand the residual threats for
the different approaches.

  Erik

---

From: Jari Arkko <[email-masked]>
Date: Sun, 13 Jan 2002 17:55:18 +0200

Erik Nordmark wrote

> you'd still use the same BU security mechanism.

I agree.

> in the security considerations section?

ND can be secure with IPsec, but only in the context of small and
fixed networks. On larger networks, the manual keying gets too hard,
particularly due to the funny way IPv6 invents new multicast addresses.
Remember that you can't use IKE for ND keying since to run IKE you
have to discover the peer's address... it's a chicken and egg problem.
Given that you don't have automatic keying, you'll have to give up
also replay protection, which could have interesting implications if
someone bothered to think about it for a while.

Jari