Re: Security requirements for identification

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

Dave,

> I claim that the validation that needs to be performed, as a result 
> of using multiaddressing, is at the time of address _selection_. ...
> The only reasonable way to do that is for the initiator to have a
> basis for trusting the pool of available addresses. Hence, it is the
> process of building that pool that requires a serious validation
> mechanism, not the process of using addresses from the pool.

I pretty much agree with the statement above, with a small caveat,
explained below.

mb> (To overcome this issue, mip demands a periodical exchange of
mb> nonces so that the identity of the other end of the communication
mb> is verified periodically)

> Let's ask: What does the periodic exchange detect or fix? ...
>
> Or is the concern that the IP address now being used for the target 
> is not valid?

More or less yes.  This is one example of what are called
"time shifting" attacks in the MIPv6 security terminology.

> This is certainly a problem that already exists with monoaddressing,
> but it is significantly exacerbated by multiaddressing, since
> multiaddressing introduces an automated mechanism for adding new IP
> addresses to the pool. However it is not the _use_ of the address
> that is the problem.

Well, it is not the _use_ of the address itself which is the
problem.  It is the expected dynamic nature of IPv6 addresses.
That is, if we expect that all IP addresses become more or less
ephemeral in the IPv6 world, then we must also expect addresses
to be passed over from one node to another.  Even subnet prefixes
will be passed from one organization to another.  This may cause
prolems with multi-addressing.

The problem is fairly subtle, though, and may not be very bad.
It becomes bad only if you can *anticipate* an address someone
else is going to use in the future, arrange yourself at that
address (so that you can pass the test of adding the address to
the pool at your peer), leave, and wait for your victim to
arrive.  Then, at that point, you can flood your victim by
claiming that you are no more available at your other addresses,
thereby forcing the peer to use the (now) victim's address.
You claim will be trusted since the address is already in the
pool.

> It is the event of adding a new target address to the initiator's 
> pool of addresses for the target. Regular use of the nonce in packets
> might detect a failure condition. However, strongly protecting the 
> mechanism for adding to the pool will accomplish the same thing, and 
> it will do it with lower packet overhead. And it will do it as 
> pre-hoc prevention, rather than post-hoc detection.

In my opinion, strongly protecting the adding mechanism is really
the most important point.  It may be also useful to include a
check whenever you start to use a locator after a long period of
inactivity, even if the locator is already in the pool.

Arranging an attack where you use a given address and stop using
it just before your victim arrives and starts to use it seems
to be very hard, and probably not worth worrying about.

> mb> (BTW I read the address ownership expression fro the first time 
> in Pekka's mb> draft "An Address Ownership Problem in IPv6" mb> 
> (<draft-nikander-ipng-address-ownership-00.txt>))
>
> Sounds interesting, but I am not finding that in the I-D depository.

It was two or three years back, long expired.  A backup copy can
be found on my web site,

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

--Pekka Nikander