Subject: A method to prevent DoS in IPv6 DAD and Mobile IPv6

From: Pekka Nikander <[email-masked]>
Date: Sun, 18 Mar 2001 11:27:52 +0200

A number of recent ID:s have shown a number of potential 
security deficiencies in the way IPsec is used in a number
of IPv6 signalling functions, including Duplicate Address
Detection (DAD) and Mobile IPv6 Binding Updates (BUs).  The
relevant drafts include the following.

   draft-arkko-icmpv6-ike-effects-00.txt
   draft-nikander-ipng-address-ownership-00.txt

The so called PBK-keys (draft-bradner-pbk-frame-00.txt)
attemts to solve the Mobile IPv6 related problem by
proposing a new class of identifiers, EIDs.  In some respects
that approach is similar to the HIP approach.

While thinking about the problem, an idea of using the IPv6
interface identifier as a cryptographic token appeared to me.
That is, by generating the interface identifier from components
using a cryptographic one-way function, one can "bind" the
interface identifier to the components, and the base security
on the components. 

The idea is very new, and comments are solicited.  Currently a
working copy of the forthcoming -00 drafts is available at

http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-pbk-addresses-00.txt

I'll be working with the draft during my flights to Minneapolis,
posting is as soon as drafts are accepted again.  

There is currently a plan to discuss related issues at the Mobile IP 
WG meeting and the SAAG session on Thursday.

--Pekka Nikander
  Ericsson
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: gabriel montenegro <[email-masked]>
Date: Sun, 18 Mar 2001 14:32:28 +0100

Wow! I came up with the same scheme, although as part of a slightly more general mechanism.
I've only been discussing with a couple of folks including Claude Castellucia and Erik Nordmark.
But your  message prompts me to send my stuff in as well. We should  talk in Minneapolis.
I had to name these things something, and based on the fact that what's important about them
is the fact that they are: statistically unique and cryptographically verifiable, I just called them
SUCV's. So we have SUCV identifiers and SUCV addresses. The latter are the ones you
mentioned in your previous note.

I attach my notes, although they are not yet complete nor in internet draft format.

The attachments are:

    1. my notes on pekka's address ownership, PBK and claude's privacy extension drafts
    2. proposal and thoughts on SUCV's

-gabriel
--
Gabriel Montenegro (Sun Microsystems Laboratories, Europe)
29, chemin du Vieux Chene         Email: [email-masked]
38240 Meylan, FRANCE              Mobile: +33 673 99 56 62
Office: +33 476 18 80 45 (sun internal: x38045)
Fax:    +33 476 18 88 88

Notes on V6 address ownership problems

http://search.ietf.org/internet-drafts/draft-nikander-ipng-address-ownership-00.txt

protection against hijacking of valid addresses requires cryptographic

authorization for operations that modify routing (BU's, source routing,

etc)

quoting from above draft: "Currently there exists no specified mechanism

for proving address ownership in Internet-wide scale."

Mini Proposal:

remaining use of redirect operations: they are only allowed with

non-global addresses which are bound (via a cryptographically sound binding)

to anonymous or pseudonymous addresses

the above constitues perhaps the only rule that operates by default, allowing

any other more dangerous operation only if authorized by strong cryptographic

mechanisms

Notes on PBK

http://search.ietf.org/internet-drafts/draft-bradner-pbk-frame-00.txt

temporary public/private pair

EID = hash(publicComponent)

Initiator sends EID to Responder

Initiator sends publicComponent to Responder

Note

This exchange must be secure, but it is an improvement over cookies.

Initiator sends (BU, EID)Priv to Responder

Problems:

does NOT really address the address ownership problem of any publicly routable

addresses

it is not specified how the EID and public component of the PK are sent

by the initiator to the responder

preventing hijacking and MIM attacks depend on this sequence if not clearly

specified

might as well make it secure: use HIP and its sequence

Notes on simple privacy extension for Mobile IP v6

http://search.ietf.org/internet-drafts/draft-castelluccia-mobileip-privacy-00.txt

What it hides: home address in the following two situations:

MN initiated traffic: hides home address from CN (a server?) and eavesdroppers

CN initiated traffic: hides home addr from eavesdropper (not from CN) What

it does not hide: home address from initiating CN's when the MN

is a server/responder

Basics:

MN's instead of their home address use a 128 bit identifier called TMI

digest for TMI' = MD5 ( Home address | digest of TMI )

define a new TLA (16 bits) for TMI address space

[why not SHA-1 (also required by IPSEC) given the collision resistance

issues with MD5?]

Works as follows:

mobile initiator

uses TMI as home address.

CN sends to TMI@COA (where the addr before

the @ is carried within the home address option

mobile responder

"CN knows the MN's identity by definition" (?)

[Maybe not, if the CN can initiate to a HIP (or TMI) entity and resolve

the COA by some other means.]

In this case, the MN can still hide its location (COA) by using a bi-directional

tunnel with its HA and not sending any BU's to the CN.

traffic MN to CN would be of the form: homeAddr@TMI@COA

requires a new destination option to carry the real homeAddr

subsequent packets have just the TMI (essentially an SA), [so why not just

use IPSEC]?

Still has problems

TMI does not prevent hijacking as explained in the nikander draft on addr

ownership

this is the problem our new default trust rule addresses (in conjunction

with HIP)

There may be issues with its use of MD5: WeaknessInMd5

Proposal

Given that:

The addr ownership problem is real. BU's and other exchanges which alter

routing or tunneling open up DOS attacks. PBK attempts to solve these,

but does not succeed for globally routable addresses.

Privacy concerns are also real, and the privacy extensions aim to solve

this.

Neither of the above solves both at the same time, yet independently, both

require non-trivial changes to BU's and other formats, as well as to the

handling of SA's and IPSEC.

The obvious solution is to address both:

Privacy

Address ownership

In one common mechanism.

I suggest it be based on HIP:

For all the cases at hand (v6 based) the HIP handshake provides for a very

good and DOS-resistant sequence.

For new application layer cases (hinted at by PBK, and applicable to P2P,

for example), the sequence must not be left up to the application. This

may be easier to do with TCP in which existing frameworks could be extended

(BEEP, TLS), but not immediately obvious how to accomplish it for UDP traffic.

SCTP is another matter.

-- GabrielMontenegro

- 18 Mar, 2001 - 12:40:30

Statistical Uniqueness and Cryptographic Verifiability

The Need for a Common Solution

The idea is to propose one common mechanism that can solve two problems
dealt with in AddressOwnershipAndPrivacyForMipV6:

address ownership: Given the different ways of altering routing information,
and in particular, binding updates received at a correspondent node, how
does this CN decide if it should heed it?

privacy for MIPv6: Mobile IP allows a node to keep the same home address
as it changes its point of attachment to the network (care-of address or
COA).

There are proposals to solve each of the above. However, these proposals
require modifying Mobile IP v6 and/or IPSEC separately. Instead, this is
an attempt at using a common mechanism to achieve both of those goals.

This note does not look at the problem from the point of view of practical
Mobile IPv6 deployment, as it could be applied to, say, 3G or 4G wireless
networks.

Here, the assumption is that we have a network in which the nodes inherently
distrust each other, and in which a global or centralized PKI or KDC will
never be available. This is more akin to Peer-to-peer and to opportunistic
networking.

The goal is to arrive at some fundamental assumptions about trust on
top of which one can build some useful communication.

Statistically Unique Cryptographically Verifiable ID's (SUCV ID's)

How does a node preclude other parties (eavesdroppers, correspondent nodes,
etc) from gleaning too much information about its identity, or its home
address or its whereabouts?

The latter concern leads to ephemeral forms of addresses which typical
proposals base on cryptographic hashes. These identifiers (or EID's or
TMI's or HIT's) can have several interesting characteristics:

they are distinguishable from globally routable addresses

they are doled out from a separate TLA (TMI's)

they have a special form which may include an administrative prefix (HIT's)

because they are based on cryptographic hashes, they are statistically
unique

this, of course, depends on the anti-collision properties of good hash
functions

perhaps MD5 is to be avoided because of some concerns in this regard: WeaknessInMd5
( http://www.cs.ucsd.edu/users/bsy/dobbertin.ps
)

they are the hashes of a public component of a self-generated Public Key
(perhaps unsigned Diffie-Hellman)

So these identifiers have a strong cryptographic binding with their public
components (of their private-public keys). This is exactly the purpose
that certificates have. There is a catch, as always. The name or identity
must be communicated securely, otherwise there is a possibility of man-in-the-middle
attack (which is reduced if the initiator also signs the source address,
and if there is ingress filtering, etc).

Whereas in other applications of self-signed certificates it is possible
to secure this step, in the situation at hand (opportunistic security)
there is no practical way to do this. Instead, the initiator must communicate
its identity/name to the responder using in-band mechanisms. Barring this
detail, the initiator proves he owns this self-signed certificate by signing
stuff with his private key, and given the algorithmic characteristics of
the hash used, he further shows that his identity is statistically unique
(within bounds set approximately by the birthday paradox).

Let's call them Statistically Unique Cryptographically Verifiable
ID's, or SUCV ID's.

Because of this, once a CN obtains information about one of these identifiers,
it has a strong cryptographic assurance about which entity created it.
Not only that, it knows that this identifier is owned and used exclusively
by only one node in the universe: its peer in the current exchange. Thus,
it is safe to allow that peer to effect changes (via BU's, for example)
on how this address or identifier is routed to. Notice that with publically
routable addresses, this assurance is much harder to arrive at, given that
the address may be 'loaned' to (not owned by) the peer in question, perhaps
thanks to the good service of a friendly DHCP server, for example.

Despite the fact that currently there is no way to prove address ownership
in the Internet, these considerations lead to the following fundamental
assumption:

redirect operations are only allowed with SUCV ID's

The above constitutes perhaps the only rule that operates by default, allowing
any other more dangerous operation only if authorized by strong cryptographic
mechanisms

SUCV ID's versus SUCV Addresses

What should one use: pure identifiers with no routing significance or addresses?

For example, in the Mobile IPv6 case, a node could just start using
its current care-of address (CoA?)
as if it were its home address, and issue binding updates accordingly when
it moved in the future.

Of course, regular CoA?'s
will not qualify under the rule above, so it would mean it might be very
difficult (impossible?) for whoever sends this BU to prove that it 'owns'
that CoA?
address and can rightfully send redirects for it.

The most the node can do is to establish some cryptographic evidence
that it is sitting on that CoA?
address. And it is sitting on as opposed to owning , because
the former more accurately describes what is going on (from the CN's point
of view at least, and maybe also in reality).

With a CoA?
that is not an SUCV ID it is never evident to the CN that whoever was sitting
on that address actually owns it. At the very most, the CN's peer can prove
that at some point it was sitting on CoA?,
and later it can prove it is still the same node, but now sitting on another CoA?.

But it cannot prove ownership. It may have obtained the CoA?
from a DHCP server, for example. Ignoring this subtle distinction leads
to DOS and hijacking attacks.

Problems may also arise because of honest mistakes in configuration.
For example, say node A was originally sitting on CoA?,
and then moved on to CoA?'.
Suppose it then asks its CN's to redirect traffic to CoA?'.
In the meanwhile, the original CoA?
may have been assigned to another node B, perhaps by the DHCP server that
rightfully 'owns' that address. The result is that now traffic meant for
B has been redirected to A at its new location.

Relying on ingress filtering may limit the risk, but essentially, the
only way for a node to prove ownership of an identifier (in the absence
of any other centralized or global mechanism), is for it to prove that
it created this statistically unique series of bits.

Once you bite into using a 'home address' that is not really your home
address, then what you're really trying to do is to use some identity instead
of an address. And if you use identities that satisfy the conditions outlined
above, then you suddenly gain the tremendous advantage that anybody can
safely believe you when you claim you own that identity. Hence they can
safely heed your redirects when you say that your identity is now available
at some different CoA?
(and later at another). Furthermore, you do not rely on ingress filtering
to limit exposure.

The only advantage to using an address is that the data traffic need
not carry extra information in the packet to guarantee proper delivery
by routing. One could, perhaps try to achieve both purposes by creating CoA?'s
that can serve as both an address and as an SUCV ID.

This could be accomplished by:

using the top 64 bits from your routing prefix (as in rfc3041)

defining the bottom 64 bits as an SUCV ID

Using the resultant 128 bit field gives you an identifier that is routable,
avoiding the need for taking extra space in the packet by sending routing
options UNTIL you move and send a BU indicating this identifier is now
available at another CoA?.
This would leak information as to your whereabouts (or at least where you
were at some point) to eavesdroppers. The top 64 bits also tells them where
that identity began to be used, which could be very important information.

On the other hand, if you use a 'pure' SUCV ID (without any routing
significance), then your packets will always need extra information somewhere
to assure they are routed properly. Eavesdroppers may still know where
that identity is at any particular point in time. This is unavoidable.
But at least they will not know where (under what prefix) that identity
began to be used.

When to use SUCV ID's versus SUCV addresses

All in all, if one is more concerned about privacy then using an SUCV ID
with no routing significance seems preferable.

As often (perhaps even more), nodes are not particularly interested
in privacy. But they (rather their users) are definitely interested in
using Mobile IP v6 such that their BU's are heeded. Since this implies
proving address ownership, these nodes would want to use SUCV home addresses
. If they do so, CN's can safely heed BU's for these addresses, because
they have reasonable confidence that in doing so they are not unwittingly
participating in some DOS or hijacking attack. This follows because of
the SUCV property of the lower 64 bits within the address.

This SUCV-ness, by solving the address ownership problem, helps in both
cases:

applications in which routing redirects need to be heeded (of which MIPv6
BU's are but one example), and

applications in which privacy is the main concern

Only that in the former(no privacy, regular use) you want a routable address
for optimization as in an SUCV home address, and in the latter you want
an SUCV ID.

With CoA?'s
it is perhaps a little different in the sense that you nodes no not have
to prove ownership, so SUCV may not be as necessary. However, if privacy
is a concern then randomized CoA?'s
(SU CoA?,
without the CV part) are quite useful (as has been pointed out elsewhere).

Proposal for a Solution

Using these ID's or addresses depends on also communicating safely the
SUCV portion, and this, in turn is dependent on the packet sequencing,
etc. These concerns are not addresses at all in the PBK draft. On the other
hand, HIP includes mechanisms and detailed considerations in this regard
(protection against replay, DOS and MITM attacks). This is why this note
proposes that a solution be drafted based heavily on HIP:

http://search.ietf.org/internet-drafts/draft-moskowitz-hip-03.txt

http://search.ietf.org/internet-drafts/draft-moskowitz-hip-arch-02.txt

http://search.ietf.org/internet-drafts/draft-moskowitz-hip-impl-01.txt

We assume MIPv6

Use HIP identities, in particular, anonymous HI's

since we assume v6 here, use HIT the 128 bit long operational representation
of HI's

HIT takes the place of EID's in PBK or of TMI's in the privacy for mip6
draft

TODO: continue this entire section!

-- GabrielMontenegro
- 18 Mar, 2001 - 13:22:02