Subject: about Wedgelayer 3.5 / Fat IP approaches

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 24 Jun 2004 17:53:21 +0200

Hi,

Among the multiple approaches that have been included within the 
Wedgelayer 3.5 / Fat IP class, we can find very different mechanisms 
imho. I I think that additional discussion is needed to understand 
which one of the different approaches (not particular solution, but 
general approach) would better fulfill our needs. the goal of this 
message is then, to provide my opinion of some of the benefits and 
limitations of each approach in order to foster discussion of this 
topic.

So, as is see it the approaches included within the Wedgelayer 3.5 / 
Fat IP class use the following types of ULP identifiers:
- 128 bit long CBIDs (HIP, SIM)
- CGAs (cb64)
- Locators (i.e. the use a locators as the ULP id) (NOID, ODT)
- ephemeral ids (WIMP, MAST?)

Each approach use different mechanisms to prove identifier ownership:

- 128 CBID and CGAs use the crypto nature of the id to prove it
- When using locators as ids, there seems to me that there are two 
proposals:
       - a reachability test i.e. exchanging cookies . imho this 
approach is
         not good enough, since in order to prevent time shifted 
attacks, you
         need to exchange cookies periodically, which is opposed to the 
fault
         tolerance requirement
       - a third trusted party (i.e. the DNS) which informs about the 
locators
         assigned to and identifier, meaning that the endpoint that is 
reachable
         at the given locator(s) is the owner of the identifier
- when using ephemeral ids, the requirement to prove id ownership is 
weaker, and only a mechanism to verify that the same endpoint is at 
different locators is needed. This can be achieved using different 
crypto mechanisms and pbk and hash chains are proposed. However, only 
the initiator can use ephemeral ids, in the case of the receiver, a 
third trusted party (i.e. the dns) is used to link the id and the 
locator, so that the initiator knows that the endpoint reachable at 
these locators is the owner of the id

In addition different approaches use different mechanisms to verify 
that an endpoint is authorized to use a given locator:

- 128 CBID, CGAs use a reachability test i.e. verifying through a 
challenge response mechanism that the identifier owner is reachable at 
the claimed locator
- the locator approach use a third trusted party (i.e. the DNS) to 
discover which locators are bound to an identifier
- The ephemeral id approach uses both mechanisms described above

Each solution imposes different amount of additional cost to a 
communication. I  guess that the cost can be measured with respect to 
the following parameters: processing, overhead

- 128 CBID, CGAs and ephemeral ids impose different degree of crypto 
which requires processing by the end nodes. Locator based need no 
crypto so no additional cost is imposed. However, i kind of agree that 
it can be assumed that the required crypto operations will be performed 
rarely, so probably this cost is acceptable.

- All proposals require additional packet exchange and while i have not 
yet compiled the amount of packets required per each proposal, i kind 
of recall that most proposals impose more or less the same amount of 
additional packets (i really not sure about this, so i would really 
appreciate if someone could correct me here)

A tricky issue that has appeared repeatedly during last discussion 
would be the referrals and call back support

- 128 CBID and ephemeral ids approaches don't seem to provide a proper 
support for referrals and call backs, since is not possible to obtain 
an locator set from the id

- locator based and CGAs will use a "valid" locator as an id, so this 
locator can be used when making referrals. IMHO, this is as good as it 
is possible to get. I  mean, a mh capable node can pass a referral to a 
non mh capable node. In this case, the non mh capable node only can 
handle a single locator, so no need to have multiple ones (well, 
perhaps having one that certainly works could help). If the node that 
receives the referral is also mh capable, it can use a mapping service 
(like the reverse DNS) to obtain the rest of the locators. Both CGas 
and locator based approach could provide such support, i guess

Finally, imho an important aspect is the applicability scope of the 
proposed solution. imho approaches that introduce a new crypto based 
identifier namespace (128 CBID, cgas) have an applicability scope that 
is broader that just multihoming, since they can be used to support 
mobility, and imho they are providing useful tools to achieve a more 
secure internet. OTOH, the other solutions are basically focused on the 
multihoming problem and their applicability scope is limited to 
multihoming ( i can't see other aspects of the Internet that could be 
improved by the adoption of such solutions)

Regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 27 Jun 2004 16:51:46 -0700 (PDT)

> - ephemeral ids (WIMP, MAST?)

What I'm about to write might make things more confusing, but hopefully
also more clear.

I think conceptually we are using identifiers for two different purposes,
but in many (not all) cases the same bit strings serve both purposes.
1. A handle passed to the applications that can be used for things like
    - comparisons
    - callbacks and referrals
2. A thing used inside the multi6 (sub)layer as part of preventing redirection
   attacks.

A current case where they are not the same is in the (now expired) cb64 draft,
where the application sees a 128-bit handle with IP address semantics,
but the multi6 layer uses the 64 last bits as a hash of a public key.
In Santa Monica after the meeting Jukka Ylitalo brought up another interesting 
thing to try; using NOID-style AIDs with WIMP ephemeral IDs underneath.
(Sounds a bit complex to me, but well worth exploring to further our 
understanding in this space.)

Furthermore, we definitely need to be concerned about #1 for existing 
applications. But it migth also make sense to think about applications
that have been modified to be multi6-aware.

For instance, calling the getpeername() API might return what is essentially
a designated locator for the peer, which provides support for unmodified
applications. But we could decide to crate getpeerid() and getpeerlocators()
which would return more information to modified applications.
This might mean that unmodified applications would receive limited 
support for callbacks and referrals when a locator becomes unreachable,
but the modified applications would be robust against such failures.

   Erik

---

From: Jukka Ylitalo <[email-masked]>
Date: Mon, 28 Jun 2004 11:09:14 +0300

>2. A thing used inside the multi6 (sub)layer as part of preventing redirection
I agree. I would like to speak about the 'context ownership problem' in
the second case. For example,

- HIP has two different kind of application identifiers: Local Scope 
Identifiers
for IPv4 sockets, and HITs for IPv6. In both case, the HIP layer uses
public key crypto to prove the ownership of the same context.

- WIMP uses ephemeral identifiers and hashes of FQDN at application layer.
However, it uses hash chains to prove the context ownership.

>understanding in this space.)
Thanks for bringing this out. Yes, the initiator would use, WIMP kind of,
ephemeral identifiers (random numbers), and the responder,
NOID kind of, routable IP-addresses at the application layer.

>that have been modified to be multi6-aware.
I feel that we should use routable identifiers with the connect()
and sento() kind of function calls in any case. This makes it possible 
to be
backward compatible with existing applications. However, the client
side may use non-routable application identifiers. (Thus, the context
establishment is asymmetric process, and two host may finally have two
diferent context-pairs with them.)

It would be also possible to change HIP in a way that the applications
were to see routable IP-addresses, instead of HITs.  Basically, the Multi6
enhanced HIP would implement a NOID kind of AID-locator split. In this way,
it would be possible to use HIP in an opportunistic mode, like SSH.
I believ that the application layer will be the key element when 
combining different
wedge3.5 proposals.

Finally, the application identifier type is related to security 
properties of
any Multi6 protocol. As Marcelo wrote, we should  analyze those
properties of different AIDs better and apply them with context
ownership properties.

>but the modified applications would be robust against such failures.
-- Jukka

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 28 Jun 2004 12:01:47 +0200

>     - callbacks and referrals

I would add initial contact to this list. I mean, an initiator must 
have a stable string to properly indicated the other endpoint of the 
communication.

> 2. A thing used inside the multi6 (sub)layer as part of preventing 

This would be essentially what pbk deals with, i guess

Would it be correct to say that the applications have to be aware of 
the string used for #1 but it is not required that apps are aware of 
the string used for #2?

(i am highlighting the *internal* of the #2)

> understanding in this space.)

this would mean that you would use hash chains values for #2 and 
regular ip addresses for #1?

> but the modified applications would be robust against such failures.

Another case, imho would be to consider a non multi6 aware application 
running on a multi6 aware host.
In this case, the multi6 layer could provide enhanced services and 
preserve connectivity even if the locator used on the refferral or call 
back becomes unreachable.
So i guess that we can have 4 cases:
a- non multi6 aware app running on a non multi6 aware host: in this 
case a locator must be used for refferals
b- non multi6 aware app running on a multi6 aware host: in this case 
the app will pass the 128 bit string that it is using to the other end. 
So the multi6 layer has to be capable to obtain the locator set form 
this 128 bit string i.e. we need an id to locator mapping mechanism
c- multi6 aware app running on a non multi6 aware host: the app could 
pass both the id and the locator set, We don't need nothing more than 
upgrading all the apps :-)
d- multi6 aware app running on a multi6 aware host: both solutions work 
fine

imho, an appealing approach would be one that uses valid locators as 
ids, in order to support a) and since we are using locaotrs, we can use 
the reverse DNs to provide the mapping system needed for b)

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 28 Jun 2004 12:15:37 +0200

> NOID kind of, routable IP-addresses at the application layer.

The problem is that some apps may need to make a refferal of the 
initiator, which AFAIU is using an ephemeral id.
I mean, by using a stable id for the receiver you solve the problem of 
the initial cntact, but imho not the refferal problem, since the 
initiator can also be reffered. I mean, apps that are not client/server 
wouldn't be properly supported by this model, afaics

> properties of different AIDs better and apply them with context

what about cgas?
They are locators, so you can use them for refferals to non multi6 apps 
and hosts, they allow to map from id to locators using reverse dns, and 
they are crypto in nature
seems a good candidate to me :-)

regards, marcelo

PS: i will reread the CB64 draft

---

From: Jukka Ylitalo <[email-masked]>
Date: Mon, 28 Jun 2004 13:39:31 +0300

marcelo bagnulo braun wrote:

> initiator can also be reffered. I mean, apps that are not 
> client/server wouldn't be properly supported by this model, afaics
>
Well, you are right.

Next, I try to replace the current WIMP identifiers with NOID kind of AIDs
for both end-points; in the next WIMP I-D. The ephemeral context 
identifiers together
with hash chains would then be used only to identify the context. 
Basically, they would
serve the same purpose as the purpose built-keys for initiators.
That is, epheral context identifiers could be used to prevent attackers 
from stealing
a context. (I'm trying to figure out how to bind a specific application 
identifier to
a specific context.)

(snip)

>
> what about cgas?
> They are locators, so you can use them for refferals to non multi6 
> apps and hosts, they allow to map from id to locators using reverse 
> dns, and they are crypto in nature

That is one alternative. However, there are some IPR issues that must be
probably solved before applying cgas with multi6.

> regards, marcelo

br, Jukka

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 28 Jun 2004 05:41:54 -0700 (PDT)

> seems a good candidate to me :-)

A downside of CGA approaches is that they would, on a global basis,
cast the /64 subnet prefix boundary in stone forever.
This is different than SeND which only assumes the /64 on a single link,
and one can envision SeND evolving to handle different subnet prefix lengths
over time.

Different people probably have very different level of concern for
"/64 forever in stone" ranging from it being a good simplification
to a fatal repeat of the 8 bit IPv4 network number + 24 bit host number
(before Class B and C was invented).

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 28 Jun 2004 05:35:53 -0700 (PDT)

> have a stable string to properly indicated the other endpoint of the 

Agreed.

> This would be essentially what pbk deals with, i guess

Yes, whether DH type pbks or hash chains - just different flavors
of constructing a purpose-built secure channel.

> the string used for #1 but it is not required that apps are aware of 

Yes.
There are even some APIs, such as the Java ones, that allow the applications
to be unaware of even #1 by having the applications only operate using FQDNs,
but I suspect that many/most applications which do callbacks and referrals 
need to be aware of #1.

> regular ip addresses for #1?

Yes.

> running on a multi6 aware host.

That was what I meant by "existing applications" above; existing application s
on non-multi6 aware hosts would just speak IPv6 as currently defined.

> this 128 bit string i.e. we need an id to locator mapping mechanism

It is actually more constrained than that since other instances of
the application might be running on non-multi6 aware hosts.
So the conservative approach would be to always hand an IP address/locator
to unmodified applications, that way the application can use it
for callbacks and referrals without any constraints on which hosts the
different instances of the app is running.

> upgrading all the apps :-)

But this would require that the application contain the logic to discover
the ID and locators for its peers, whereas when running on a multi6-aware host
the application could leave that task to the host (libraries etc).
So it adds complexity to do this in the application, and there doesn't
seem to be much benefit because the non-multi6-aware host would not be
capable to make TCP connections survive a locator change etc.

> the reverse DNs to provide the mapping system needed for b)

Yes, if the solution is going to rely on the reverse DNS for other purposes
this makes sense. But if the solution doesn't, then we shouldn't require
that the reverse DNS be maintained IMHO. It would be fine to take
advantage of it for more robust referrals and callbacks, but not assume it
will be there.

  Erik

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 28 Jun 2004 16:02:54 +0200

> That is, epheral context identifiers could be used to prevent 
> attackers from stealing
> a context. (I'm trying to figure out how to bind a specific 
> application identifier to
> a specific context.)
>

I guess that we should see the details before commenting but in 
abstract terms, my concern would be:

In its current form WIMP uses:
- A hash of the FQDN as id of the receiver, and it uses the DNS to 
provide the required security. I mean, the mapping between the id and 
the FQDN is direct (id=hash(FQDN)). Next, the map between the FQDN and 
the locator set is provided by the DNS system (so you trust a third 
party to obtain such information) and so you know that if you send 
packets to those locators you are reaching the desired id.
- for the initiator, you use an ephemeral id. In this case, you don't 
need to worry about all the threats, since the ephemeral id won't be 
valid for following communications. Basically, the only thing you need 
to worry about is that the endpoint that is communicating remains the 
same. You don't worry about id hijacking since the id is ephemeral (so 
it will become meaningless in a short while)

Now, you are proposing to use long lived ids for the initiator as well. 
In this case, you solve the refferal problem, but the price is that you 
now have to consider all the threats that you were not considering when 
using ephemeral ids. So you need a mechanism to prove the initiator'r 
id ownership. In other words, imho hash chains are not enough in this 
case, and you need something else. NOID uses the DNS, HIP uses the 
crypto nature of its ids, what would be the mechanisms here for this?

> probably solved before applying cgas with multi6.

Yes, but those issues are being worked out in other wg, as in SeND, and 
imho we could be optimistics about this... (but my opinion on this 
matter is even more meaningless than in other topics, so...)

regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 28 Jun 2004 07:33:15 -0700 (PDT)

> it will become meaningless in a short while)

I think it is the FCFS per-peer allocation of the ephemeral ID that matters.
Basically you don't need to worry about premeditated redirection attacks
because, should a node discover that "its" ID is being used by somebody else
at a particular peer, it can just invent a new empeheral ID and try that one.

Thus WIMP doesn't require that the ID be renewed at any particular frequency;
an ephemeral ID might be used for years. But due to the FCFS property
a new ID might be allocated any time some new communication is attempted.
For all I know the node can continue to use the previous ID when communicating
with other peers long after the conflict had been detected at a particular
peer.

> crypto nature of its ids, what would be the mechanisms here for this?

Don't know yet. One could potentially do the union of all of the above
(yes, complexity alarms are ringing - but I still want to understand this
stuff and see how bad it would be) including exploring weaker approaches
like RR.

  Erik

---

From: Jukka Ylitalo <[email-masked]>
Date: Tue, 29 Jun 2004 09:44:43 +0300

> abstract terms, my concern would be:
Thanks for your valuable comments Marcelo and Erik. We are currently 
working on the details,
and I will get back to the issue later in the form of WIMP-01.

>
>
> ...something else. NOID uses the DNS, HIP uses the crypto nature of 
> its ids, what would be the mechanisms here for this?
>
That is a very good question, and Erik already gave a short answer to 
this. We
just have to figure out what are security implications of this and if 
this works,
how it works. 

br, Jukka

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Jun 2004 13:49:46 +0200

> (before Class B and C was invented).

Good point. The /64 boundary is only "architectural" in one place, stateless
autoconfig, and even that is a changeable decision.

CGAs have other downsides for multihoming, too.

    Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 29 Jun 2004 16:28:14 +0200

> CGAs have other downsides for multihoming, too.

such as?

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 30 Jun 2004 17:46:53 +0200

El 30/06/2004, a las 17:29, Brian E Carpenter escribió:
> <chair hat off>
> I really don't want to start a discussion here about cryptographic
> strength, but my objection to CGAs in the multi6 context is that they
> include the /48 prefix in the hash, and that is variable in multi6,
> which means that the host ID changes when you change prefix. I think
> that's an unfortunate property because it eliminates some possible
> tricks in the ID/locator split.
>

Well, probably it is my fault for using the wrong terminology, but i 
was considering cgas as a concept rather than the specific approach 
followed by the send wg.
for instance you can consider the cb64 draft or even the ideas 
discussed between Iljitsch and Jari about including all the prefixes or 
some other workarounds.

My point was basically that having a string that it can be used as a 
valid locator and that it also has a crypto nature would provide 
several benefits, since it enables a way to prove its ownership and 
apps can treat it as a regular ip address

Makes more sense?

regards, marcelo

PS: it is clear that if we are going to use one locator as ULP id, the 
id will have to change when renumbering, the benefit of this, is that 
apps still handle ip addresses and that most of their assumptions still 
hold.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Jun 2004 17:29:04 +0200

<chair hat off>

    Brian