Subject: Identifiers

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 23 Mar 2004 16:22:38 +0100

Looking at the proposed solutions, it seems that we have been 
gravitating towards locator agility without explicit identifiers. While 
that's certainly a valid approach, I think we should take a few moments 
to consider identifier issues.

The main reason to forego having identifiers is that it is hard to 
determine if a correspondent is rightfully using an identifier. 
However, this is not the case for two classes of potential identifiers:

1. Identifiers with a cryptographic nature, such as the ones proposed 
for HIP. Since the identifier is a hash of a public key, proving 
ownership is trivial given a few round trips and CPU cycles.

2. FQDNs with a certificate that leads back to a trusted authority. 
These are in relative wide use today for SSL.

It stands to reason that future developments will lead to new types of 
verifyable identifiers. I think this invalidates the assumption that 
verifying the authenticity of identifiers is too hard a priori. Rather, 
the question should be whether we are willing to accept the necessary 
complexity to allow extensible identifier authentication in our multi6 
solution of choice. In this regard, it should be interesting to see 
what the MOBIKE people are up to.

Personally, I think the best choice would be to remain agnostic about 
the identifier issue for now, but build our negotiation protocol such 
that they can be added easily later. For now, we build a "no 
identifier" type solution. Solving the problem of how a correspondent 
proves ownership of an identifier can then be deferred until such time 
that someone actually wants to extend the multi6 solution to support 
identifiers. So the only thing we have to do now is make sure the 
protocols are flexible enough to allow such extensions.

Thoughts?

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 23 Mar 2004 16:44:19 +0100

Hi Iljitsch,

[...]

> protocols are flexible enough to allow such extensions.

I am sorry, but i fail to understand what would be usage for such protocol.
I mean, until you provide the security features, we cannot deploy the
protocol, since it would be unsafe to adopt it, so what's the point on
having it defined?
Moreover, if you try to define a protocol that is general enough to support
all the different authentication mechanisms, i guess it will be more complex
that a protocol that actually relies on a defined mechanism.
I agree that the issues right now w.r.t. preserving established
communications is about choosing a security mechanism, so IMHO if we want to
provide a solution for this problem we will have to make our mind and decide
something on how to do this.
I guess that the architectural analysis is conceived to provide the required
background to make such choice.

But, perhaps i misunderstood your proposal?

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Mar 2004 17:02:19 +0100

Iljitsch,

Good input. We might think in terms of a Level 1 architecture in which
the ULP still fondly believes that an IP address is a good identifier,
and a Level 2 architecture where something that can be authenticated
is used (and the ULP needs to be profoundly modified).

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 23 Mar 2004 17:20:02 +0100

Hi Brian,

[...]
> the ULP still fondly believes that an IP address is a good identifier,

By address, do you mean any 128 bit long string or a routable IPv6 address?
I guess that ULP protocol can work fine with any identifier whose
representation can fit into 128 bits.

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Mar 2004 17:26:49 +0100

> representation can fit into 128 bits.

Exactly. That is all a ULP knows - a binary string shaped like an IPv6 address.
It has no knowledge of the locator-like properties.

    Brian

---

From: "Kanchei Loa" <[email-masked]>
Date: Tue, 23 Mar 2004 09:58:31 -0700

Hi Iljitsch,
I personally prefer  solutions with identifier or identifier extension as
you described. But I thought this
WG is still at architecture analysis phase, which is agnostic to all
proposals.

---------
Kanchei Loa
[email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Iljitsch van Beijnum
> Sent: Tuesday, March 23, 2004 8:23 AM
> To: Multi6 List
> Subject: Identifiers
>
>

---

From: Francis Dupont <[email-masked]>
Date: Tue, 23 Mar 2004 18:17:35 +0100

In your previous mail you wrote:

=> can I translate this statement into a generic "authorization" issue.

   
=> note that ownership is not authentication.

=> this implies some kind of PKI but provides strong authentication.
We can get both: in HIP "anonymous identifiers" are 1 and other
identifiers are 1+2, at most one identifier (the initiator's one)
can be anonymous.

=> IPsec/IKE requires strong authentication (i.e., 2) by default.
IMHO it can be lowered to what HIP requires, i.e., at least 1 for
the initiator and at least 2 for the responder in some contexts.

   Thoughts?
   
=> I disagree because the security, in this case a proper handling of
the authorization issue, must be included in the design from the
beginning.

Regards

[email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 23 Mar 2004 18:17:36 +0100

> protocol, since it would be unsafe to adopt it, so what's the point on

Well a winter coat isn't much use in the summer but things change.  :-)

> something on how to do this.

I agree, in order to build something that's usable we need to select 
one way of doing this, and standardize and implement this way of doing 
it. And a good way to do this would be taking working sessions and 
negotiate alternative addresses for them, without the use of an 
explicit identifier. However...

> But, perhaps i misunderstood your proposal?

What I'm saying is that even though it may not make sense to have full 
blown identifiers _today_, it's probably a good idea to recognize that 
we'll want to have them in the future, and make sure the actual 
multihoming protocol we're going to build now can be easily adapted to 
support identifiers. This means that there must be unused or option 
fields in the messages that can be used to extend the protocol in a 
backward compatible way. Another important issue is that when 
identifiers are used, all negotiation must precede the actual 
communication, so we should build our protocol that it allows this if 
at all possible.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 23 Mar 2004 18:42:36 +0100

> WG is still at architecture analysis phase, which is agnostic to all

I was hoping to kickstart some architectural discussion with my 
original message in order to be able to leave this agnostic phase 
behind us at some point.  :-)

Iljitsch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 24 Mar 2004 00:28:51 +0100

> => note that ownership is not authentication.

Hm, I was working on the assumption that we only need authentication, 
as the owner/holder of an identifier or a locator can do with it what 
he or she pleases. Would it be useful to add an authorization step to 
this process? I.e., despite the fact that I know you are indeed the 
legitimate holder of your identifier, I may still refuse to interact 
with you because you haven't been authorized to use the identifier for 
this particular purpose. But then the question becomes: who grants 
authorization?

> => this implies some kind of PKI

Yes. My point is that there is something that can be called a PKI for 
SSL.

> identifiers are 1+2, at most one identifier (the initiator's one)

Indeed. The initiator doesn't even have to use an identifier.

> the authorization issue, must be included in the design from the

Good point, building something first and then trying to plug the holes 
doesn't work very well. However, what is "the beginning" here?

There are two claims that we want to check when a correspondent claims 
that it is reachable at additional addresses: the "who" part and the 
"reachable" part. (We don't want someone else to claim that their 
addresses belong to our correspondent, but we also don't want our 
correspondent to claim that someone else's addresses are theirs.) The 
the "reachable" part is universal: once we create a protocol, this part 
shouldn't change. However, the "who" part depends on the nature of the 
identifiers. Without actual identifiers we only check whether we're 
talking to the same entity, regardless of who this entity is. But with 
cryptographic identifiers, we can actually check whether someone who 
claims to be the holder of the identifier has the secret key. With a 
PKI the procedure is different, with DNSSEC different again.

Now what I'm saying is that we should build a "no identifiers" type 
solution *now* but recognize that we may want to have identifiers 
later. At some point, the protocol is extended to make it possible to 
use a certain type of identifiers. Since this is the beginning of the 
use of these identifiers, this is also the beginning of or security 
efforts with regards to using these identifiers. In other words, it 
makes no sense to include X.509 handling _now_ if we are building an 
identifier-less solution.

However, there are some things we can do to make it easier to support 
X.509 certificates in the future. For instance, use length fields that 
are more than 8 bits. In practice there may not be a huge difference 
between building a general purpose system that supports just option X 
at this time and a special purpose system that only supports option X, 
but philosophically there is a world of difference. "When the only tool 
you have is a hammer, every problem looks like a nail." So taking the 
hammer first and then consider the problem limits our view of the 
solution space. Considering the problem, then determining that we can 
solve most of it with a hammer and deciding that we can only afford a 
toolbox with a hammer in it at this time is very different.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 24 Mar 2004 10:31:24 +0100

he or she pleases.

=> obviously we don't share the meaning of the word "authentication" here.

   Would it be useful to add an authorization step to this process?

=> yes, and the authorization is the real thing!

   I.e., despite the fact that I know you are indeed the 
   legitimate holder of your identifier, I may still refuse to interact 
   with you because you haven't been authorized to use the identifier for 
   this particular purpose.

=> this question is another form of "authentication doesn't imply
authorization".

   But then the question becomes: who grants authorization?

=> some kind of trust system including local policy, PKIs, ...

   
   
=> the current SSL/TLS heavily uses X.509 PKIs.

   
=> I disagree: without an identifier remote redirection is insecure.
An "anonymous identifier" is an identifier because it has ownership,
it is anonymous because it can't be bound to a name.

   
=> IMHO any kind of proposal which can be implemented (things which can't
be implemented can be a waste of time but should not endanger security :-).

=> DNSSEC can be used as a PKI, i.e., some PKIs are not based on X.509.

   later.

=> perhaps you mean we need only ownership and not strong authentication?
In anycase we need identifiers, the question should be about the needed
properties of these identifiers.

   At some point, the protocol is extended to make it possible to 
   
=> do I catch your idea?

   However, there are some things we can do to make it easier to support 
   X.509 certificates in the future.

=> when I disagree with the "no global PKI" of some people at the IETF,
I agree that a global X.509 PKI is not possible and even not desirable.

   For instance, use length fields that 
   
Thanks

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Mar 2004 11:23:06 +0100

Our problem is not ownership. It is surviving changes in existing connectivity
without opening the door to hijacking or DoS. All we need to authenticate
is that after a multihoming event, we are still talking to the same
entity at the other end.

   Brian

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 24 Mar 2004 12:17:12 +0100

> explicit identifier. However...

Ok, basically you are proposing to use one of the available IP addresses as
the identifier used by ULP, and then eventually introduce a new namespace
for identifiers which may provide with enhanced features.
The question now is how do you provide security for this negotiation of
alternative addresses in this first stage?
Because you will need to provide some sort of security even in this case.
The good thing about some other namespaces is that make the security
simpler, so when you want to use IP addresses, you need to solve the
security issues somehow, without these features provided by the new
identifier namespace.
So what would you think would be the security tools used for negotiating
multiple addresses in a solution that used IP addresses as ULP ids?

> support identifiers.

Well, whichever solution we adopt to preserve established communication, i
guess that we have consensus that it will imply the upgrading of all the
hosts, inside and outside the multihomed site to support it (modulo
proxies).
So, if we agree that a new id namespace provides value and that should be
the final solution, why don't we just go for it and we require only one
upgrade to all the hosts in the Internet? (Actually this was your argument a
while ago, i am just quoting it because i found it very valuable :-)

Regards, marcelo

 This means that there must be unused or option

---

From: Jari Arkko <[email-masked]>
Date: Wed, 24 Mar 2004 14:14:39 +0200

> Our problem is not ownership. It is surviving changes in existing connectivity

I suspect "ownership" is not defined in the above context well
enough to say whether it is or is not a part of our problem.
I agree that ownership as in "IANA has allocated this address
to me" is not an issue for multi6. On the other hand, address
ownership has also been used in other meanings as well, e.g.,
in SEND its "this address has been created by this node". This
might be within multi6 scope.

> is that after a multihoming event, we are still talking to the same

Yes. Quoting a dictionary:

   Identity
      From Latin idem, ‘the same’.
      1. Sameness ...

So I believe the issues of identities and checking
the sameness of the entity at the other end are
the same thing (no pun intended).

> determine if a correspondent is rightfully using an identifier.

It is indeed necessary to determine this. But of course its
trivial if its a cryptographic identity such as HIT or CGA.
If its a human assigned identity, such as [email-masked],
it would be much more troublesome (I don't recommend this).

More importantly, note that even if you don't have identifiers,
there's still a need to determine if the correspondent is rightfully
claiming a multihoming event. So I believe the rightfullness /
sameness check will be needed in any case.

Iljitsch wrote:

> For now, we build a "no identifier" type solution. 

Based on the above, I tend to think that we will always
have an identifier, the only question is how explicit/implicit
it is, and whether the identifier is a new identifier or an
existing one (such as FQDNs and IP addresses in NOID). The
other differentiator is how good security you get for
tying the protocol exchanges to the identifier, e.g.,
cryptographic signatures vs. relying on DNS.

--Jari

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 24 Mar 2004 13:29:16 +0100

> for identifiers which may provide with enhanced features.

Yes. (Another way to look at the first part would be not having 
identifiers at all.)

> alternative addresses in this first stage?

Since we have return routability there is no need to prove ownership of 
the first IP address. Additional IP addresses can be checked against 
information provided over the first one, so we can be sure that all of 
them are used by the same host. However, a man in the middle between 
one end and the original address of the other hand can subvert this 
process in the absense of some kind of out of band security 
information. My answer to this problem is that there is no need to 
create such an out of band system (storing info in the DNS, PKI, 
whatever), as long as we can make use of such a system when it's 
present.

I think this makes sense because if you don't bother to use IPsec or 
TLS for a session, then the communication is subject to all kinds of 
nastiness from a man in the middle anyway, so protecting against 
session stealing isn't worth the trouble. On the other hand, if the 
communication is sensitive there will be IPsec/TLS anyway so having 
something in that case is redundant. We just need to make sure we can 
leverage the security information present in those protocols to secure 
our multihoming negotiations.

> hosts, inside and outside the multihomed site to support it (modulo

Do you see any alternatives? I believe geographic aggregation could be 
one, but I'm pretty much alone in that regard.

> while ago, i am just quoting it because i found it very valuable :-)

Good point. But I can think of three reasons not to:

1. Without a new namespace we can make sessions compatible with 
existing TCP as long as no rehoming events are necessary
2. Introducing a new namespace would take much more time
3. We don't know yet what kind of namespace we want, or even how many, 
so we probably need to keep our options open for adding even more 
anyway

I'm not claiming these arguments are definitive, however. One reason to 
create a new namespace would be that it should make referencing and 
then connecting to the entity referred much easier.

Iljitsch

---

From: Francis Dupont <[email-masked]>
Date: Wed, 24 Mar 2004 16:20:24 +0100

Our problem is not ownership. It is surviving changes in existing
  connectivity without opening the door to hijacking or DoS. All we need
  to authenticate is that after a multihoming event, we are still
  talking to the same entity at the other end.
   
=> this is a different problem: the binding between the identifier and
the locators and we can divide it into three parts:
 - can be the multi-homing signaling modified by an attacker on the path?
 - have we to trust the peer not to give a fake locator?
 - have we better properties about locators?
As in multi-homing we have static locators even the last part can be
a reasonable goal.
But the subject of this thread is "Identifiers" so I don't understand
your intent...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 24 Mar 2004 16:37:53 +0100

the first IP address.

=> this is highly questionable:
 - not all transport protocols give a return routability check for free
 - return routability check only constrains the position of the attacker
   (it has to be on the path during the attack).
 + multi-homing can't be less secure than standard Internet for the first
   IP address.

   Additional IP addresses can be checked against 
   information.

=> this is the mobile IPv6 routing optimization problem.

   My answer to this problem is that there is no need to 
   create such an out of band system (storing info in the DNS, PKI, 
   whatever), as long as we can make use of such a system when it's 
   present.
   
=> the mobile IPv6 answer even if the last part can be considered as
dubious, at least in some current implementations...

=> I agree but I am afraid that things are not as simple as you suggest...

Regards

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 24 Mar 2004 17:11:16 +0100

Hi Jari,

> existing one (such as FQDNs and IP addresses in NOID).

I guess that another question related to this is at which level the
identifier applies.
I mean, if you consider a solution that apllies at the transport level, like
sctp or address agile TCP, you don't have a IP level identifier.
You will have a application level identifier, i guess which will probably be
one of the ip addresses.

Regards, marcelo

>  The

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Mar 2004 17:46:28 +0100

> But the subject of this thread is "Identifiers" so I don't understand

My intent is to observe that for the problem this WG is supposed to
solve, we don't care whether the claimed identifier at the beginning
of a session is genuine. What we care about (rather like TLS) is whether
the two communicating entities remain the same even if the session suffers
a rehoming event. I don't think we are disagreeing.

   Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 24 Mar 2004 19:27:06 +0100

> Return routability procedure has an inherent problem when it is 
> applied to
> the multihoming scenario. the problem is that in multihoming, at a 
> given
> moment, the address is no longer reachable, so it is difficult to
> distinguish an outage from and attack.

Obviously the first phase of the negotiation (where we do RR for the 
initial address) must be complete before surviving an outage is 
possible.

> Please, note that when using RR it is not enough to verify the initial
> address only at the beginning, you need to verify it periodically, if 
> not,
> you are susceptible to time shifted attacks

I don't see why this would be necessary.

>> session stealing isn't worth the trouble.

> This is where i don't agree. I think we shouldn't do things worse than 
> what
> they already are (or at least not too much worse)

Someone who can intercept your communication with Google can already 
reset the TCP session so you don't get to see your search results. Why 
would the capability to redirect those search results to another IP 
address be much worse than this?

> Well, i guess that if the other end is upgraded it doesn't matter, and 
> if it
> is not, the only option is to fall back to regular IP and not use the 
> new
> ids.

You make it sound so easy.  :-)  The tricky part here is to make sure 
that communication between an upgraded host and a non upgraded host 
always works as before, while communication between two upgraded hosts 
uses the new capabilities. This makes it necessary to add some magic to 
determine the capabilities of the remote host, preferably without 
incurring any delays.

Being able to just start a session and then negotiate additional 
addresses later is a plus here. But we might be able to this by 
creating identifiers but allow the identifier space to overlap with the 
locator space. For instance, 2001:345::678 could be such a new 
identifier. Legacy hosts would simply put this value in the destination 
address. But upgraded host would execute some TBD id->loc mapping 
function and receive a set of locators. A further refinement would be 
for an upgraded host to first try to connect to the address directly in 
a backward compatible way and then negotiate additional addresses as 
per NOID/DHT. Only when this fails the id->loc database is consulted. 
(The id->loc database could also aid in securing the negotiation.)

> Why? I guess that if the id is managed, perhaps, but there are other 
> options

Because it's more work.

> Well, as is said, IMHO this is the problem that we should solve, and we
> should make a decision on this.

So what kind of identifiers would you like to see?

Iljitsch

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 24 Mar 2004 19:35:10 +0100

> a rehoming event. I don't think we are disagreeing.

I think that we may not care if the source address is genuine but we do care
that the destiantion address is genuine. I mean, if i know that the address
IPA belongs to www.foo.com (suppose that i have learned it through the DNS),
i want that when i send packets to IPA they get to www.foo.com. It would be
bad that becuase of multihoming mechanisms,when i start sending packets to
IPA, they end up in somewhere else.

The point is that if we care about destination addresses being genuine, we
may also need to care about source addresses being genuine, depending on the
sense of direction that the considered solution has. I mean, if the source
address of established communications will be used as destiantion address
for following communcations, if an attacker succeed in convincing a victim
that IPA is one of its source addresses, following communications
established by the victim to IPA will be routed to the attacker.

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Mar 2004 10:51:38 +0100

> established by the victim to IPA will be routed to the attacker.

My assumption is certainly that we can trust the first address pair, to
exactly the extent that we can trust it in a non-multihomed case. Is
that a wrong assumption?

This should be made explicit one way or the other in the threats draft.

   Brian

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 25 Mar 2004 11:35:33 +0100

> exactly the extent that we can trust it in a non-multihomed case. Is

IMHO it is a bit more tricky.

First of all, the initial comment was about general identifiers, not
restricted to addresses. Depending on the nature of the identifier it is
more or less  easier to steal a given identifier.

In the case of using addresses, return routabilibity i.e. the capability of
sending and receiving packets from/to the identifier (address) provides you
a little level of trust that the other ends owns the address (identifier).
If other identifiers are used, this level of trust may disappear (or
improve)

In the particular case of addresses, the problem with multihoming is that
verifying the addresses at the initial stage through return routability only
provides proof of ownership at this moment in time. It does not guarantee it
in the future. That is the attacker may be intercepting the packets only at
the initial stage, and then move somewhere else. If you trust an IP address
that you have only verified at the setup stage, you are exposed to this
attacks called time shifted attacks (P. Nikander et al.)

Finally, it seems that it is accepted that source addresses cannot be
trusted, but we do trust destination addresses, since we expect that packets
are delivered to that destination. However, in multihoming, the sense of
direction of source and destination may change in time. I mean, suppose that
i don't really verify a source address (or a source identifier in general)
and i just accept (without further verification) that a certain identifier I
has initiated a communication with me and it is reachable at the locators
L1,..,Ln. This may be ok, since it is not good in the current Internet to
trust the source address (source identifier)
the problem is that if i keep this state binding the identifier I with
locators L1,...,Ln as valid, i will use if in the future when i try to
initiate a communication with identifier I. Now this is problem, because i
want to communicate with I and i am trusting an unverified state linking I
to a set of locators to reach it.

> This should be made explicit one way or the other in the threats draft.

Well, some of this issues are already in the draft, and some others have
been discussed with Erik and the list. Let?s wait for the next version and
see

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 25 Mar 2004 11:59:55 +0100

> initial address) must be complete before surviving an outage is

Agree

> I don't see why this would be necessary.

Please see my reply to Brian about time shifted attacks an other similar
attacks.

> address be much worse than this?

well, this would be something like a DoS attack. i think that thinking that
you are communicating with google but in fact being in communication with
another malicious party is worse than DoS.
Some will claim that you can already do this by intercepting DNS queries,
but the point is that this sort of issues are being worked on, so we better
off if we don't add vulnerabilities, i guess.

> You make it sound so easy.  :-)

Sorry, i didn't wanted to sound as if i was over simplifying the issue that
you were cosnidering, it is just that i didn't understand it properly.

>  The tricky part here is to make sure

Agree.
How does the current proposals deal with this?
I guess that you can carry the new id in an extension header (optional
destiantion option for instance) and if the host is upgraded it will process
it and if not will just discard it and use the IP address.
The cost of this is the bit of the extension header in the first packet

> addresses later is a plus here.

I fully agree with this, but for other reasons, i guess.
I think this is a plus basically because you can avoid the additional cost
of negotiating and validating additional locators when you will not need
them, i think this was called delayed setup.
this is good for upgraded hosts.

> But we might be able to this by

This will depend on the nature of the id space that you use. Some
identifiers name space cannot be delegated in blocks like addresses (for
instance CBIDs)

> > Why? I guess that if the id is managed, perhaps, but there are other

I mean, which is the additional work related to the namespace when you are
using a self generated statically unique CBID?

> So what kind of identifiers would you like to see?

I think that CBIDs provide value to the architecture and enable clean
solutions for multiple problems.
I also think that any solution for preserving established communication will
imply the modification of all the hosts.
So if the solution requires such a high cost, it would be good to take the
most out of it.
I mean, i would rather add a functionality in all the hosts that is useful
in a general way, not just a patch to solve this particular problem.

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 24 Mar 2004 17:39:21 +0100

> Yes. (Another way to look at the first part would be not having

Well, i subscribe more to Jari's view, where in this case one of the IP
addresses is the id, but never mind, i guess we understand what we are
talking about.

> Since we have return routability there is no need to prove ownership of

I am afraid not. If there any value in the exercise of trying to use MIP for
multihoming, is that you can clearly understand the limitations of the
return routability check for the multihoming case.
Return routability procedure has an inherent problem when it is applied to
the multihoming scenario. the problem is that in multihoming, at a given
moment, the address is no longer reachable, so it is difficult to
distinguish an outage from and attack.
I mean, you the verification with RR is that you get there, but when an
outage occurs, by definition you can't get there, so RR seems a poor choice
when you will have to deal with outages.
Some patches can be made, as we have discussed with you regarding ODT, but i
am afraid that you end up with a fragile solution or with a not very secure
solution.

Please, note that when using RR it is not enough to verify the initial
address only at the beginning, you need to verify it periodically, if not,
you are susceptible to time shifted attacks

> process in the absense of some kind of out of band security

Yes, i don't think that securing from MitM attacks is a requirement.

> session stealing isn't worth the trouble.

This is where i don't agree. I think we shouldn't do things worse than what
they already are (or at least not too much worse)

> On the other hand, if the
> Do you see any alternatives?

No,no.
I was just highlighting one of the few points where i think we have
cancerous.

> I believe geographic aggregation could be

Well, i guess that if the other end is upgraded it doesn't matter, and if it
is not, the only option is to fall back to regular IP and not use the new
ids.

> 2. Introducing a new namespace would take much more time

Why? I guess that if the id is managed, perhaps, but there are other options

Regards, marcelo

---

From: Eliot Lear <[email-masked]>
Date: Fri, 26 Mar 2004 14:05:01 -0800

Marcelo & all,

It sounds like Brian started pretty darn close to where I would be:

 > My assumption is certainly that we can trust the first address pair,
 > to exactly the extent that we can trust it in a non-multihomed case.
 > Is that a wrong assumption?

I think a good solution in this space would not weaken the authenticity 
of any existing identifiers.  And this is why I liked NOID.  You want 
strong security?  The claim is that it will work with DNSSEC for 
verification.

Beyond that, if you have an existing line of communication between you 
and a host, wouldn't PBKs provide a secure means by which one could 
privately pass additional information?  If it does, it provides some 
really nice generality for the above.  For instance, if you use some 
very secure mechanism to establish connectivity then PBKs could provide 
continued assurance.  And if you were out in the open, PBKs provide less 
assurance (e.g., you still end up with potential MITM attacks).

Regards,

Eliot

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 28 Mar 2004 14:03:25 +0200

Hi Elliot,

> of any existing identifiers.

I guess that i don't understand Brian statement, then.

I mean, suppose that you have host A that uses IPA to initiate a
communication with host B sending packets to IPB.
So, Host B receives packets coming from IPA and it sends replies to IPA.
So far so good, Host B doesn't have a strong confirmation that IPA is really
the genuine identifier of HostA, but Host B knows that Host A can receive
packets addressed to IPA. That is they way it works for fixed hosts and that
is the level of security we should preserve i guess.

Now the problem how do we translate this requirement to a multihomed
environment.

Suppose the same scenario where HostA initiates a communication with HostB
using IPA and IPB respectively. They exchange some packets, so Host B knows
that Host A is reachable at IPA.

Moreover, HostB is using as a ULP identifier IPA.

Now, using some kind of multihoming mechanism, Host A tells HostB that he is
also reachable at IPC. Moreover, Host A can strongly prove that he is the
same that initiated the communication using IPA (i.e. that the same entity
who was at IPA is also at IPC)

Finally, HostA start using IPC as source address in its packets, so HostB
starts preferring IPC over IPA to use as destination address to reach HostA
(instead of changing the IP address an alternative signaling mechanisms can
be used to switch addresses)

So my question now is: do you think that HostB, once that is sending packets
only to IPC and knowing that it is same entity that initiated the
communication using IPA, should still believe that he is communicating with
IPA?

Regards, marcelo

 And this is why I liked NOID.  You want

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 28 Mar 2004 15:18:15 +0200

marcelo bagnulo wrote:
> the genuine identifier of HostA, 

Correct. That is how the Internet works. Multi6 doesn't have to fix that.
We have to make sure that *if* the host we contact using IPA subsequently
asserts that it can also be contacted using IPZ, that assertion is true.

The analogy with TLS is very strong - whoever we started talking to,
we continue to talk to. If we start talking to a bogus host, we continue
talking to the same bogus host when multihoming occurs.

   Brian
> but Host B knows that Host A can receive

---

From: Eliot Lear <[email-masked]>
Date: Sun, 28 Mar 2004 09:22:18 -0800

Hi Marcelo,

Brian responded precisely as I would have.  I believe it's a substantial 
effort simply to maintain what level of one had in the first place. 
Consider the following case:

  -- One address (IPA) is protected with DNSSEC and the other (IPA') is 
not.  What do you do?

Regards,

Eliot

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 29 Mar 2004 02:21:09 +0200

> asserts that it can also be contacted using IPZ, that assertion is true.

If i understand what you are saying correctly, this approach wouldn't really
prevent the attacks presented in section 4.1.2 Premiditated redirection of
draft-nordmark-multi6-threats-00.txt, right?

Or in more general terms, this would allow time shifting attacks as
presented in section 2.2. Timing in draft-nikander-mobileip-v6-ro-sec-02.
Note that MIP design especially limited BCE entries lifetime to a few
minutes to deal with this type of attacks.

> talking to the same bogus host when multihoming occurs.

Yes, but now, the attacker must be on the path to achieve the attack while
multihoming may allow the attacker to move from the path and continue to
perform the attack
So, allowing this type of attack adds vulnerabilities to the current
internet, AFAICS

Clearly, if the addition of these vulnerabilities is acceptable, the
solutions would be much simpler, indeed.
I just want to make sure that we agree that we are adding vulnerabilities
here, so we can make a choice then.

But i am not a security expert and i may be missing something, it would be
nice to have an experts opinion to clarify

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 29 Mar 2004 10:38:52 +0200

[People, why are we CC'ing everyone and their little sister?]

> minutes to deal with this type of attacks.

Which is of course something we can't do. As I said before, if someone 
in the middle can redirect an ongoing session, I don't consider this 
materially worse than what can happen today (disrupt the session). 
However, redirecting not only the current session but also future ones 
would be unacceptable. It doesn't seem too hard to avoid this, though: 
new sessions can be forced through a "real" address rather than a 
negotiated backup address. Unfortunately, in a NOID/DHT-like scheme 
this probably means the application needs to be involved with this. 
Example:

X publishes addresses A and B in the DNS.
Y contacts X on A
X negotiates C as an additional address
A dies
the session from Y to X starts flowing over C
Y wants to set up a new session to X
Y tries address A
address A times out
Y tries address B

And this is without adding crypto-based identifiers to the mix. Making 
all of this more flexible and more secure can be done using 
crypto-based 64 bit identifiers. I think those are a great idea, but so 
far there has been very little discussion on this topic.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 29 Mar 2004 12:27:44 +0300

In my opinion, we need to worry about the time shifting
and future redirection attacks. We also need to worry
about denial-of-service through "hijacking" some of the
used identifiers in some permanent fashion (e.g. leap of
faith after just one return routability test at the beginning
of time) and preventing the legitimate nodes from establishing
their sessions using their identifiers after the hijack has
occurred.

--Jari

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 29 Mar 2004 15:32:28 +0200

> would be unacceptable.

I agree with this criteria.
The protection for a connection can be done once in the connection lifetime.
The problem here, then is at which layer your solution is working.
If you adopt a transport layer solution which the locator set exchanged only
applies to that particular connection, the security checks can be
simplified, IMHO like one RR check.
However, if you adopt a shim layer or IP layer solution, the solution has no
knowledge about
connections, so the exchanged locator set will apply to all connections,
present and future, incoming and outgoing. That is why IMHO we have to take
care of time shifting attacks when considering shim/IP layer solutions which
may require additional mechanisms

> It doesn't seem too hard to avoid this, though:

Yes, this kind of approach can deal with these attacks.
There are other options, also.
But i guess we agree that we have to provide protection against this type of
attacks (which is good :-)

> far there has been very little discussion on this topic.

as i said in previous mails, i think CBID add value and are a good option
and of course the provide protection from this attacks.

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 29 Mar 2004 17:31:59 +0200

> may require additional mechanisms

Ok, this is a useful constraint: either our mechanisms must work 
per-session (or group of sessions created within a short timeframe) or 
we need strong(er) authentication than just return routability.

> and of course the provide protection from this attacks.

Yes. The nice thing about 64 bit CBIDs is that you can just put them in 
the bottom 64 bits and they're not in the way. This allows being 
backward compatible as long as there are no outages. It's not even 
necessary to negotiate additional addresses at this point if good hints 
towards available addresses for the correspondent are available at at 
least one end.

However, in this case the upper layers must still be aware of the 
locator bits. Having ULPs work with identifiers exclusively would be 
cooler but more complex.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 29 Mar 2004 11:02:11 -0800 (PST)

> asserts that it can also be contacted using IPZ, that assertion is true.

I sense folks talking a bit past eachother on the mailing list so let
me try to help.

In the case when nothing moves around I think we understand the requirements
quite well. Something that is on the path can be a MiTM today and
multi6 doesn't need to make that aspect any more secure.

But it is more difficult to undersyand the requirements when nodes are moving
around; a node might be on the path for a short instance (driving by
the 802.11 coffeeshop).
Would we or would we not be concerned if such a drive-by (which many call 
a "time-shifting" attack) would result in the temporarily on-path node can 
be a MiTM for future communication? (e.g. by creating/installing 
multi6 related state in various peer nodes while it was on the path) 

I actually don't think the answer is obvious; we don't have much experience
with nodes moving around being able to attack things as they move.

In Mobile IPv6 a conservative approach was taken which limits such
drive-by attacks to the maximum lifetime of the binding, which is set to
a few minutes.

Note that the range of solutions that has been discussed in multi6
go from such drive-bys being impossible (because of a strong binding to
a separate identifier in HIP, or because of relying on the relative security
of the DNS for forward+reverse lookups in NOID), to 
systems that are first-come/first-serve (WIMP being an example with
a separate ID space, a MAST approach with a PBK being an example without
a separate ID space) that allow the first host which is using an ID/address
to claim that without any time limit.

The threats draft talks about pre-mediated attacks which is a particular
aspect of "drive-bys"; things that are different because nodes move around.
Based on the mailing list discussion I suspect we need to flush out the 
this whole area of nodes moving around a bit more in the draft.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 29 Mar 2004 11:14:11 -0800 (PST)

[Catching up]

> protocols are flexible enough to allow such extensions.

Thanks for bringing up this topic.
It definitely makes sense to think about it a bit.

I can see the feasibility of constructing a protocol which can carry
sets of locators and an identifier (which might be just the designated
locator the ULP is viewing as an identifier - what I called AID in some
drafts), with messages to change the set of locators over time.

What concerns me so far are two things: implications on the initial setup
and implications of different security mechanisms.

If a separate identifier is used this means that the initial setup must
appear before (or at the same time) as the first ULP packets are exchanged.
But if we just have a locator-agile mechanism without a new identifier space
it makes sense to allow a deferred exchange (and verification) of the locator
sets e.g. to avoid this cost when the connections are very short.
I don't have a good feeling for how complex it would be to design
a protocol which can do both immediate and deferred setup.

We've seen quite a range of security approaches proposed so far, and with
different approaches to prevent using the verification of the locators
as a new avenue for DoS attacks.
Will a scheme which introduces a new ID name space by necessity need
different security mechanisms? Will be immediate vs. deferred state
setup have implications on this?
Is there a common "message sequence" which can apply independently of
the actual security mechanism being used?
(The good news is that the notion of a lazy-evaluation of the locators
and ID->loc bindings seems to become common across the proposals. So perhaps
there is a common theme to be able to verify a peer locator before it is
used which might mean a more common "message sequence"?)

   Erik

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 29 Mar 2004 23:40:47 +0200

Hi Erik,

Thanks

> with nodes moving around being able to attack things as they move.

I don't think that the decision is obvious but I think it is very importatn
ti understand the additional vulnerabilities that we are introducing. It may
be acceptable to introduce them, though.

> this whole area of nodes moving around a bit more in the draft.

Agree.
I think that the section of future attacks considers this issue but perhaps
adding some more examples to understand the full range of time shifting
attacks would be fine.
Additionally, perhaps it makes sense to explicitly note that the direction
of communications. I mean, the threats when you allow that the state created
by an incoming connection is shared with future outgoing communications.

So, there is state created at a moment in time, a time shifted attack is
about using this (false) state in future communications, but additionally,
IMHO it is also important to note whether this communication are in the same
direction of the communication that created the state.

finally, i think that explicitly noting that there is a difference level of
threat when the state affects only a connection or it refers to the complete
identity of the host.

Regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 29 Mar 2004 15:11:48 -0800 (PST)

> by an incoming connection is shared with future outgoing communications.

Yes, it is already on my todo list to add text about this to the threats
draft.

> threat when the state affects only a connection or it refers to the complete

Having text in the threats draft that points out this concern makes sense.
I don't feel we can say much more about the "granularity" of the redirection
attacks - because I don't think we understand the tradeoffs in terms
of granularity yet.

  Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 31 Mar 2004 19:06:41 +0200

> appear before (or at the same time) as the first ULP packets are 

Yes. This also means the negotiation protocol must be able to get 
through in order for anything to work, piggybacking will be very hard 
here.

(Aside: I always thought it was a big flaw in the IKE design that the 
negotiation is done with the target host. Maybe it's too hard to make 
this work safely with a third party host, but it would have some nice 
security benefits and solve rendezvous for mobility.)

> sets e.g. to avoid this cost when the connections are very short.

Right.

> a protocol which can do both immediate and deferred setup.

I'd think it wouldn't really matter. Immediate setup can be viewed as 
deferred after 0 bytes of data have crossed the line. The only 
difference is that with deferred negotiation some information we need 
(locators) is by definition available, while with immediate negotiation 
we may need to go look for it ourselves. Or am I missing something?

> different security mechanisms?

Not by definition. But some types of identifiers could support security 
mechanisms that others can't. For instance, with crypto based 
identifiers it is possible to find out whether the other side is the 
real holder of the identifier with nothing more than information 
received from the correspondent. With non-crypto IDs you need some 
chain or web of trust if the identifier is cryptographically protected. 
Alternatively, the information may not be learned from the 
correspondent but rather from a mapping service. The way such a mapping 
service works depends on the nature of the identifiers (hierarchical or 
otherwise).

So basically we have four permutations of identifiers:

- non-crypto, non-hierarchical
- crypto, non-hierarchical
- non-crypto, hierarchical
- crypto, hierarchical

We probably don't need four different security mechanisms, but more 
than one is likely if we're going to use identifiers from more than one 
category.

> Will be immediate vs. deferred state setup have implications on this?

I don't see how we can defer state setup for identifiers that aren't 
reachable locators. And identifiers that ARE locators aren't always 
reachable, placing part of the multihoming burden on applications.

> the actual security mechanism being used?

Does it matter? The messages are presumably passed back and forth 
transparently. The only important part is that we have some 
well-defined state transitions, and the security mechanism triggers the 
right one at the right time.

BTW, without knowing the details, I think 802.1x, PPP and EAP solve a 
fairly similar problem.

Iljitsch