Subject: [mobile-ip] I-D ACTION:draft-aura-mipv6-bu-attacks-00.txt

From: [email-masked]
Date: Fri, 16 Nov 2001 06:57:05 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: MIPv6 BU Attacks and Defenses
	Author(s)	: T. Aura, J. Arkko
	Filename	: draft-aura-mipv6-bu-attacks-00.txt
	Pages		: 23
	Date		: 15-Nov-01
	
This document overviews various attacks against mobile and fixed IP 
nodes by exploiting features of the Mobile IPv6 Route Optimization. 
Many of the attacks can be prevented by authenticating the Mobile 
IPv6 Binding Updates (BU) but some cannot, and some denial-of-
service attacks specifically exploit features of authentication 
protocols. The purpose of this document is to list attacks that 
should be taken into consideration when designing protocols for BU 
authentication and to outline available protection mechanisms. We 
also discuss the choice between different levels of protection.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-aura-mipv6-bu-attacks-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-aura-mipv6-bu-attacks-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-aura-mipv6-bu-attacks-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Pekka Savola <[email-masked]>
Date: Sun, 18 Nov 2001 11:40:12 +0200 (EET)

> also discuss the choice between different levels of protection.

I just read the draft quickly, and one issue popped up...

3.1: about CAM.  The ACM paper is not available on the website so I can't
check whether the issue was dealt with, and I may be confused. but I don't
see how changing one's address to match your key will change anything
about PKI.  The recipient of the packet still has to have the sender's key
it can trust. That is, either end will have to obtain (via a directory or
something) one key it knows that belongs to the other end.  This is one
sorely missing piece of PKI.

in effect,
--8<--
   A recently discovered technique [OR01] provides an intermediate 
   level of security between strong public-key authentication and weak 
   methods such as routability tests. The idea is to form the last 64 
   bits of the IP address (the interface identifier) by hashing the 
   host's public signature key. Binding Updates can then be signed 
   with this key. A secure one-way hash function makes it difficult 
   for the attacker to come up with a key that matches a given address 
   and to forge signed BUs.
--8<--

Either I'm very confused or I think this should either be:
 - source node's public signing key for last 64 bits generation, but 
signing the BU with private key.
 - _destination_ node's public signature key (doesn't seem to make sense)
 - source node's _private_ signing key (doesn't seem to make sense)
 - source node's public signing key (makes even less sense)

(for the last one, as public signature key is public knowledge anyway, an 
attacker could just obtain it off a directory and create the hash).

Editorial comments:

s/[mobile] host/[mobile] node/, in very many places; or if this is 
intended, perhaps it should be noted in a terminology section or 
something.

s/highjack/hijack/
s/a timestamps/timestamps/
s/needs to be is carefully/needs to be carefully/

check 'See Section Error! Reference source not found'
check 'mobile' -> 'mobile node'

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: "Jari Arkko" <[email-masked]>
Date: Sun, 18 Nov 2001 12:12:27 +0200

> sorely missing piece of PKI.

CAM does not need any infrastructure! Your address is (partially)
a hash of your public key, and with the private key you prove you
"own" the address. The "proof" relates to the fact that it is hard
for anyone else to find another public key that would hash to the
same value.

Therefore, no PKI is needed. The sender just sends its public key,
the address is implicit in the packet in the HOA (or similar place),
and a signature by the private key verifies the CoA.

>    with this key. A secure one-way hash function makes it difficult 

Should have been "this key" => "the private key associated with this public key".

> signing the BU with private key.

That's correct. 

> Editorial comments:

Thanks. We'll fix these.

Jari

---

From: Pekka Savola <[email-masked]>
Date: Sun, 18 Nov 2001 12:28:32 +0200 (EET)

> Should have been "this key" => "the private key associated with this public key".

Ok, with this clarification it makes much more sense.  Perhaps I was too 
literal when reading the draft :-)

---

From: Claude Castelluccia <[email-masked]>
Date: Mon, 19 Nov 2001 10:44:21 +0100

Hello,

BTW this is a great draft.

Just fews comment :
In the draft, you say:
"Another shortcoming of the CAM-type addresses is that although they
   prevent the theft of another host's address, they do not stop the
   attacker from inventing new false addresses with an arbitrary
   routing prefix. The attacker can generate a public key and a
   matching IP address in any network and use it to mount bombing
   attacks (as described in Section 2.5). ".

I thing this is not true. In SUCV (and i believe this is the same with CAM),
the MN proves the onwership of the Interface Identifier that it is using to
configure its HomeAddress...if the MN configures its CoAs with the same
Interface Identifier then the MN basically proves that it owns the CoAs...
since this Interface Identifier is statically "unique", an attacker can not
bomb someone with Mobile IPv6...

Just to summarize how this works,
-the MN generates its interface ID  (we call it SUCV HID in SUCV) from its public
key
- it then MUST generate its HomeAddress and Care-of Addresses by appending the
corresponding
routing prefix to its SUCV HID
- when a MN sends a BU to a CN, its signs it with its private key...
- the CN verifies the signature and that the SUCV HID was generated
from the public key...

As a result, an attacker can only use MIP to bomb someone if it is able to build a
SUCV HID that
is equal to the victim's interface id. This is very difficult....
So by advocating to use the same SUCV HID than the Home Address for the Care-of
addresses you solve
the bombing problem you mention....for free...

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

---

From: Pekka Savola <[email-masked]>
Date: Mon, 19 Nov 2001 12:07:47 +0200 (EET)

> bomb someone with Mobile IPv6...

[snip]

> is equal to the victim's interface id. This is very difficult....

I not so sure about that, depending on the network usage patterns of the
victim.

If you'd want to bomb an arbitrary node at random, it would be 
difficult... 2^64 is a big number..

If you'd really want to bomb a certain node, you'd by definition already
know it's address, or at least something significant about it.  Other data 
could be gathered from web server logs, traffic analysis, irc 
/whois etc.etc.

I believe getting the interface ID would not prove too difficult if you 
really wanted to.  This could be avoided by extensive use of privacy 
extensions, but mandating that wouldn't be possible..

---

From: Claude Castelluccia <[email-masked]>
Date: Mon, 19 Nov 2001 11:14:44 +0100

> extensions, but mandating that wouldn't be possible..

Pekka,

sure it is easy to know someone address and interface id ...but in order to
bomb this address you need to prove that you can generate it (i.e you know
a valid Pub/priv key pair that hashes to it) and this is not very easy...

There is nothing about privacy here...you don't need to hide your address...
i really don't get your comment...am i missing something?

regards,
Claude.

--

---

From: Pekka Savola <[email-masked]>
Date: Mon, 19 Nov 2001 12:52:31 +0200 (EET)

I may be very confused but you said:

>-the MN generates its interface ID  (we call it SUCV HID in SUCV) from 
>its public key
>
>- it then MUST generate its HomeAddress and Care-of Addresses by 
>appending thecorresponding routing prefix to its SUCV HID
                                                  ^^^^^^^^
[snip]

>As a result, an attacker can only use MIP to bomb someone if it is able
>to build a SUCV HID that is equal to the victim's interface id. This is
            ^^^^^^^^
>very difficult.... So by advocating to use the same SUCV HID than the
>Home Address for the Care-of addresses you solve the bombing problem you
>mention....for free...

SUCV HID is generated and used as an IP address with the prefix.  The 
attacker could either snoop or otherwise get to know the address used (ie 
prefix + SUCV HID), and start attacking.

Or am I off the mark here?

---

From: Claude Castelluccia <[email-masked]>
Date: Mon, 19 Nov 2001 12:01:47 +0100

> Or am I off the mark here?

I think you are (or am it?).
The attack described in draft-aura-mipv6-bu-attacks-00.txt consists
for an attacker to redirect its traffic to a victim by using the victim address
as CoA...for example, the attacker starts few big ftp transfers and then sends
a BU to each server with the victim address as CoA...the ftp will then be send to
the victim....

This is worse than snopping an address and bombarding it directly...

Claude.

--

---

From: Pekka Savola <[email-masked]>
Date: Mon, 19 Nov 2001 14:15:53 +0200 (EET)

> This is worse than snopping an address and bombarding it directly...

You're right.

In case it'd help some others too, I'll try to explain the problem in 
other words:

1. Attacker may know the prefix + SUCV HID of the victim
2. Attacker may know the public key of the victim
3. Attacker may set his own prefix + SUCV HID of the victim

However,

4. Attacker cannot reverse SUCV HID to get the private key, therefore
Attacker cannot send BU which would have to be signed with it.

As pointed out it's still possible, though, to do e.g.:

1. Attacker generate a public + private key which generates SUCV HID #2
2. Subscribe to some heavy traffic to his prefix + SUCV HID #2
3. Send autheticated BU to the source, and redirect the traffic to 
victim's prefix + SUCV HID #2.

The chances, unless certain widely used suffixes are reversed, of victim's
prefix + SUCV HID #2 being used in the netwrok are quite small, but the
network is still congested.

However, I'm not 100% sure how much different this is to certain reflected 
DoS attacks today, e.g. send an ICMP echo request with src=victim, 
destination=reflector. (well, this could not be prevented by ingress 
filtering at least).

I was confused, and thrown off by your statement:

> As a result, an attacker can only use MIP to bomb someone if it is
> able to build a SUCV HID that is equal to the victim's interface id.
> This is very difficult....

Building (by snooping, ...) SUCV HID is easy, but finding out the matching 
private key isn't..

---

From: Michael Thomas <[email-masked]>
Date: Tue, 20 Nov 2001 16:12:53 -0800 (PST)

> and a signature by the private key verifies the CoA.

Jari,

I too have only managed to skim this, but what
prevents me from source spoofing an address for
which I've done keygen and signed? Is this a
threat? Also: this seems to imply that you
wouldn't be able to the normal MAC address (sorry,
I always forget its proper acronym) mechanism, or
any other well known formats. In particular, I'm a
little bit worried about not being able to be a
mobile node which responds to anycast addresses,
or perhaps a node which wants to remain anonymous,
yet still be able to do route optimization. Is
this feasible?

		Mike

---

From: Greg Daley <[email-masked]>
Date: Wed, 21 Nov 2001 16:15:50 +1100

Claude Castelluccia wrote:
[previous responses snipped]
> a BU to each server with the victim address as CoA...the ftp will then
> be send to the victim....
> 

	Hello Claude,

	I'm just catching up on this discussion, but regarding the HMIPv6
	draft which you worked on, wouldn't SUCV prevent the extended mode
	form being readily adopted (Since the assumed RCoA in Extended Mode
	is another node (the MAP)'s Global IP address and the MN cannot form
the
	correct SUCV HID for this RCoA).

	Do you see this as an idea which should deprecate HMIPv6 extended mode,
	if it were to become the adopted interface identifier scheme?

	Not trying to stir the conversation too much, but since you 
	have an interest in both SUCV and HMIPv6, it would be interesting
	to see how you rank the proposals in importance (or whether you see
	a way around this yet).

		Greg Daley

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Nov 2001 10:55:07 +0200

Michael Thomas wrote:

> which I've done keygen and signed?

The CAM procedure itself does not protect against
this, but note the following: (1) If you generated
a key and an address from it, you are not hijacking
any existing nodes because the addresses would be
different, so in a way this is not a threat. (2)
Procedures
run under or before CAM (such as BAKE/2 -- see the CAM-DH
draft) would be able to show return routability, so in
order for the attacker to succeed he'd have to be for
instance in the home network. If he's there, he could do
also other damage.

> Is this a
> any other well known formats.

Yes, IEEE address format wouldn't be used. You'll
also be re-generating the key and the address now
and then for added security, so it is possible that
mobile servers might wish to make use of Dynamic DNS.

> In particular, I'm a

I think anon MNs are quite feasible. Just run your
RFC 3041 procedure by generating a new key now and
then.

As for the anycast case, I'm somewhat uncertain how
mobility and anycasting would fit in together anyway.

Jari