RE: Security requirements for identification

["marcelo bagnulo" <marcelo@it.uc3m.es>]

Dave,

> mb> Not really. Current mono-addressing IP security relies on
> routing (id=loc so
> mb> if you trust the routing system then it will deliver the packet to the
> mb> correct IP==ID)
>
> The question is how the IP address is obtained. _Using_ an IP address when
> there is multiaddressing also relies on the routing system to deliver the
> packet to the correct IP address.
>
> What is different is that multiaddressing introduces a way of
> _changing_ that
> original IP address into another one. Although the sender still
> chooses which
> IP address to use, the multiaddressing proposals all provide new,
> automated
> ways of slipping those new addresses in.
>
> So my point is that multiaddressing creates a security challenge
> not because
> delivery is changed but because address selection is changed.  In
> the past,
> address selection really was easy.  Somehow you decided on using
> one.  Then
> you stayed with it.  Now you may not.

Well, i think the problem is that the application (perhaps not even the
transport layer) is not aware of the change.
I mean, suppose you establish a tcp connection with a host far away using
its IP address IPA. In the mono-addressing scheme, you know that this
address will remain the same.
In the multi-address, the  layer below tranpsort may change the address
being used to IPB but this is not visible to the transport layer and above,
i mean, the transport and above still think that the connection is
established with IPA. (this is the case where you use an IP address as
identifier, such as mip)
So now the ip address used in the communication has changed and the only way
to prove the address ownership has been lost, but for the other end of the
communication the IP address involved in the communication is still the same
(IPA)


>
>
> mb> So current mono-address ip does perform a verification that
> the other end of
> mb> the communication remains the same in EVERY packet.
> mb> This scheme of nonce validation only verifies the id of the
> other end at the
> mb> begining of the communication (or when a new address is included).
>
> With mono-addressing, the target gets a packet with a destination
> IP address
> and validates that it -- the target -- is that IP address.  With
> multiaddress,
> this does not change.
>

I guess the key point is who performs the validation...
In multi-addressimg the validation is performed by the new shim-wedge layer
that handles the multiple addresses, but the application is not aware of the
change.

Let's consider an example.
Suppose that i want to establish a communication with a server A. In order
to do that i have to know its address, IPA. HEre is where the validation is
done for this address IPA. I mean i have to know IPA somehow (this is not
part of the things that IP layer does for you). Once that i Know IPA and i
have validated it, i can establish the communication. Now, ip gives me some
guarantees that packets will be delivered to the server A as long as the
destiantion address included in packets is IPA.

If multi-addressing is enabled, and i try to do the same. Then i have to
discover one IP address of the server A, (IPA) and validate it in the same
way than before (i.e. IP layer doesn't do this for me). Now i establish a
communication with server A sending packets to IPA. Now, if multi-addressing
is enabled, alternative IP addresses can be exchanged by the shim layer and
they will be used to reach server A. This means that while my tcp connection
is still established with IPA (that i have validated with some mechanism),
packets can be actually addressed to other addresses that have been
validated by the shim layer (and the worst and also the best part is that
not even tcp is aware of the situation)


The other option is to let the application to be aware of all the addresses.
In this case, the validation of all addresses can be performed in the same
way (not done by the ip layer, done in some other way)
The problem here is that you have to modify all the apps to let them handle
multiple addresses.

> With mono-addressing, the target gets a packet with a source IP
> addresses.  It
> might or might not "validate" it by sending a return packet.  With
> multiaddressing, this does not change.
>
> So, the per-packet validation that is created by adding a per-packet nonce
> does a validation that is new. It well might be a useful
> validation, but it
> really has nothing to do with multiaddressing.
>
> I claim that the validation that needs to be performed, as a
> result of using
> multiaddressing, is at the time of address _selection_. This is at the
> initiator's side, prior to use. 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 think i covered this above but let me synthetize.
With mono addressing all you need to know that a given server A has a given
IP address IPA
With multi-addressing you have two options AFAICS:
First, you idscover all the addresses available in the other end in the same
way that you discover IPA in the mono address sheme, for server A, you
discover somehow that it has IPA1, IPA2,...
This option is not really good enough because you have to know all the
possible addresses to be used a priori (which would be acceptable for
multi-homing but it is not good enough for mobility) and because it implies
that all apps have to be modified to support this. So the goal is to leave
the apps as they are and handle the multiple address issue transparently.

The second option is that you discover one address as in the mono-address
situation IPA, and then the shim layer discover address that are equivalent
to the initial IPA. This validation is different than th initial one and has
to be performed in a transparent manner.

>
> mb> (To overcome this issue, mip demands a periodical exchange of
> nonces so that
> mb> the identity of the other end of the communication is
> verified periodically)
>
> Let's ask: What does the periodic exchange detect or fixe? It
> uses a secure ID
> to ensure that the IP addresses being used are legitimately among the pool
> associated with the endpoints belonging to their respective
> identifiers. More
> importantly, it validates that things have not _changed_. What could have
> changed between uses of the nonce?
>
> Could the routing system have started sending packets with the
> same IP address
> to a different place? If this is the concern, it certainly is
> legitimate, but
> has nothing to do with multiaddressing.
>
> Or is the concern that the IP address now being used for the target is not
> valid? 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.
>
> 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.

Pekka's has already answered this, i guess.


>
>
> >> However validly, we trust DNS entries and IP routing. As soon
> as you worry
> >> about whether to send an identifier in the clear, you are considering
> >> something far broader than problems caused by multiaddressing.
> mb> I don't completelly agree. Today you can establish a
> communication using
> mb> only an IP address (you can avoid using the DNS for security
> reasons) So i
> mb> don't think is reasonable to say that all ip addresses are as
> weak as a
> mb> communication that involves a dns query (if we can say this,
> the security
> mb> problems would be greatly reduced). I do agree with the routing part.
>
> My reference to DNS was simply not note that domain names serve
> as identifiers
> and that the mapping to IP addresses is a process that is used
> with serious
> expectations of validity. Yes, the packet service does not
> require you to use
> it. But the application-level Internet really does rely on the
> validity of the
> mapping.
>

I agree with you.
My point is that current architecture provides the ability to establish
communication that are more secure than those that use the DNS (i.e. using
IP addresses direclty)
If we introduce a id to locators mapping like the DNS and its usage becomes
mandatory to establish a communication,, the result is that communications
are less secure, since you don't have the cappability of avoiding the
threats introduced by the DNS-like mapping system.

>
> >> PN> In the first case, the only secure way of performing
> >> PN> identification seem to be public key cryptography (or any of
> >> PN> its variants, like zero knowledge protocol).  The reason for
> >> PN> this is the following.  Since the identifier is public
> >> PN> knowledge, we cannot use the identifier directly.
> >>
> >> Today, we use domain names and IP addresses in the clear.  And
> things work
> >> pretty well.
> >>
> >> To use Marcelo's phrasing, we do not "prove we own" the domain
> >> names are IP addresses we use.
>
> mb> You do prove that you own the IP address, the routing system does it.
>
> The routing system validates the association between the target
> (destination)
> IP address as an address and the IP address as an identifier.
>
> It does not validate the initiator (source) address. Any such
> validation is
> performed by a return packet, using the larger context of the endpoint
> association.
>

Agree.

Regards, marcelo

>
> 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.
>
>
> d/
> --
>  Dave Crocker <dcrocker-at-brandenburg-dot-com>
>  Brandenburg InternetWorking <www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>
>
>
>
>