Subject: RE: Identifier/locator recap

From: "Bound, Jim" <[email-masked]>
Date: Sun, 16 Mar 2003 23:40:56 -0500

> > Could you write up your technical idea without a lot of man 
> hours to 
> > describe and why it solves the multihome problem.
> 
> I'm not Tony, but:
> 
> Traditional multihoming as is done in IPv4 will not scale.
> 
> An alternative is to give each host in a multihomed site an 
> address for each ISP the site is connected to. When (the link 
> to) one ISP fails, the communciation is diverted over the 
> other ISP. However, current transport protocols are unable to 
> jump to new addresses in mid-session. Solution: separate the 
> identifier and locator functions of the IP address. Transport 
> protocols then use the identifier, which doesn't change 
> during the lifetime of the session, while IP uses the 
> locator, which may be changed at any time in order to route 
> around broken parts of the network.

I think the MIPv6 MHH is on the right track and it is an excellent piece
of technical work.  I have read it twice and I believe it could work.

But I also like the note to all in GAPI which states we have two sets of
space. THe unicast space and the MHH space.  I for now like that
thinking model.

> 
> A few things that need to be addressed to make this happen:
> 
> - Locators must always be present in each packet. But what about the
>   identifiers? Do we include them in each packet (= tunneling) or are
>   they implied?

If we can make them implied its an extra condition check for routers and
hosts but will make the overall architecture less heavy and less to
manage.  I believe in overload though it is complex to implement not
impossible.

> 
> - How do we discover identifiers and/or locators?

Still parsing the PI space MHAP.  But that is on the right road.

> 
> - How to we authenticate the relationship between locators and
>   identifiers?
> 
> There is also the question of what makes good identifiers. 
> HIP uses the fingerprint of a cryptographic key. MHAP uses 
> provider-independent IPv6 addresses that aren't visible in 
> the global routing table. I myself have suggested to use 
> FQDNs as the first choice.

I suggest not being dependent on crypto anything is wise it implies PKI
to the solution and I fear that is a non-starter?

> 
> Note that there seems consensus here that we shouldn't try to 
> revive GSE or 8+8: some kind of "16+16" would be much easier 
> to deploy.

No comment.  I agree with Tony lets get the Macro done.

I do think we need to work on the Model so it is clear to all and then
we can do the architecture and then apply implementation discussion?

/jim
> Iljitsch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Mar 2003 09:26:30 +0100 (CET)

> manage.  I believe in overload though it is complex to implement not

Routers don't have to do anything, just the end points. Having the
identifier in each packet really doesn't buy you any simplicity since
the relationship between the locators and identifiers must be
authenticated to steer clear of endless security troubles.

> to the solution and I fear that is a non-starter?

No, HIP is smarter than that. But what I find troublesome with that
approach is that the identifiers are a flat 120+ bit space which makes
it incredibly hard to create a distributed way to look up properties for
identifiers.

> we can do the architecture and then apply implementation discussion?

Sounds good to me.

Iljitsch

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 17 Mar 2003 18:44:11 +0859 ()

Jim;

> of technical work.  I have read it twice and I believe it could work.

No. MIPV6 is on IP layer having no idea on proper time out values,
which depends on transport/application layers, and is not a solution.

							Masataka Ohta

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 17 Mar 2003 06:38:32 -0800

> it incredibly hard to create a distributed way to look up properties for

Not really.  Distributes hash tables (DHT) should work.  Somebody
just need to work out the details; they are not exactly simple, though.
But not that complicated either, I would believe.  See the proceedings
of recent peer-to-peer conferences and you will find multiple occasions
where DHTs have been used.

--Pekka Nikander

---

From: Pekka Savola <[email-masked]>
Date: Mon, 17 Mar 2003 17:01:02 +0200 (EET)

On Mon, 17 Mar 2003, Iljitsch van Beijnum wrote:
> No, HIP is smarter than that. [...]

Uhh, no.  HIP requires either DNSsec or opportunistic key distribution a
la SSH.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 17 Mar 2003 07:15:16 -0800

Pekka Savola wrote:
>>No, HIP is smarter than that. [...
> 

Opportunistic key distribution a la SSH works pretty well.

Going further, HIP *without* DNSsec/PKI is slightly *more*
secure than today's insecured TCP/UDP, even if HIP is used
to implement mobility and/or multihoming.  See our security '
analysis in our recent NDSS'03 paper.

However, if you want to use HIP to secure something that
goes beyond mobility or multi-homing, or want to achieve
a security level that is more than slightly more secure
than the current unsecured IPv4, you have to rely on
DNSsec, or accept the vulnerabilities in opportunistic mode.

Summary:  HIP without DNSsec or PKI can provide security
for mobility and/or multi-homing that is acceptable according
to the current security requirements.

--Pekka Nikander

---

From: Pekka Savola <[email-masked]>
Date: Mon, 17 Mar 2003 17:34:33 +0200 (EET)

> to the current security requirements.

Not having read the paper, I think we agree -- what's basically left is 
on-the-path attackers, local attackers or DNS-based forgery.  All of those 
are also problems in the unsecured IPv4.  DNS-based forgery may be a bit 
easier though, but that might need more analysis.

However, my complaint with HIP model is that it seems so closely tied to
ESP and security.  Is it possible to use HIP without IPsec ESP?  Or do you
have to use ESP with null encryption?

The security model above is possibly ok if the user gets no assumption 
that "because I use HIP, I must be secure now".

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 17 Mar 2003 07:46:01 -0800

> have to use ESP with null encryption?

There is no architectural reasons why you couldn't use HIP
without ESP.  For example, you could use two IP headers,
the inner one carrying HIP ids (HITs) and the outer one
locators, i.e. conventional IP addresses.   However, what's
the point, it would take 40 bytes, and ESP takes less.  You
can always use ESP with null encryption, and even with no
integrity protection if you really want.

Now, we have had some loose chat about how to use HIP without
any extra headers, i.e. just an IP header followed by TCP/UDP.
However, given that we would have to be prepared to talk to both
HIP enabled and non-HIP enabled hosts at the same time, it would
require some trickery at the kernel, and that might be brittle.

If you loose security requirements even more, it would even be
possible to use opportunistic HIP without the Diffie-Hellman
key exchange, but that would be vulnerable to bidding down
attacks.  Thus, I haven't bothered to think about that any further.

--Pekka Nikander

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Mar 2003 18:16:42 +0100 (CET)

> where DHTs have been used.

Hm, I'm not very familiar with this technique and I can't find a good
explanation of how it applies to the problem at hand right now. But it
seems to me that such a distributed system is very vulnerable to
malicious nodes holding back information that they are supposed to
share. Also, the self-organizing could make unsuspecting nodes attract
more traffic than they can handle.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Mar 2003 18:24:18 +0100 (CET)

> Opportunistic key distribution a la SSH works pretty well.

It works a lot less well if you don't have local storage to keep the
keys, or if node A wants to refer node B to node C.

The problem I see with HIP is that you can't initiate a session with
just the identifier to identify the host you want to communicate with.
Now that would be fine if it were possible to feed this identifier to a
lookup engine and get back something you _can_ use to initiate a
session. But this isn't possible either. So effectively the HIP
identifier serves no identifying purpose.

> to the current security requirements.

Cool. Now if only it could provide functionality...

Note that I'm not anti-HIP. I'm sure there are problems that can be
solved by HIP. But it can't be a general solution for multihoming as it
only moves the problem to a different area.

Iljitsch

---

From: Eliot Lear <[email-masked]>
Date: Mon, 17 Mar 2003 10:31:06 -0800

But it is possible.  We needn't forsake DNS entirely...

Eliot

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 17 Mar 2003 13:07:54 -0800

> just the identifier to identify the host you want to communicate with.

You are right.  More work is needed.  As I wrote, someone
should work out the details how to utilize DHTs, perhaps
in conjunction with DNS.  Or something similar.

> session. But this isn't possible either. 

I would say that _currently_ such a mechanism does not exist.
But I would *not* say that it is not _possible_.  The fact
that such a solution does not currently exist does not make
it impossible to create one.

I have a hunch that a DHT based solution should not be too
complicated.  However, to really see how DHTs would fit in
to the DNS model would require some kind of an idea how DNS
servers are going to be distributed in the IPv6 space, and I
don't currently have any good guesses for that.  If someone
could provide one, that might help.

The question is really about load balancing between DNS
servers so that no one gets too much load.  Integrity is
not much a problem.   I see some potential DoS problems,
but it is easy enough to provide completely independent
servers with DHT structures.

> So effectively the HIP

I couldn't understand that.  Could you please explain?

> only moves the problem to a different area.

So you want me to come up with a completely worked out solution?
Cool!  :-)   Should I will crawl back to my research cubicle until
I find someting?  :-)

More seriously, personally I believe that HIP has large potential
for end-host multi-homing.  Much more than the ID->locator
mapping I see the crypto overhead (Diffie-Hellman) as a problem.
There are also lots of other details to be worked out, with time.
Furthermore, HIP is definitely not a solution for doing large site
multi-homing, other solutions are needed for that.

--Pekka Nikander

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Mar 2003 23:03:38 +0100 (CET)

> in conjunction with DNS.  Or something similar.

As I said, I'm not up to speed with DHT but I can envision something
like this: the address space is spread out as a flat one-dimensional
space, where everyone who has a prefix points to a number of others
higher and lower (For instance, x + 1, x + 2, x + 4, x + 8 for higher
and so on). Then you can do something close to a binary search by
jumping up and down through the address space from server to server in
ever smaller jumps.

This could work extremely well except for one tiny problem: what if some
nodes don't cooperate and don't follow the protocol?

> it impossible to create one.

This is essentially the same old problem: looking up entries in huge
piles of data that lacks a hierarchical structure simply doesn't scale.

Maybe this is already in there (I can't remember the latest HIP
identifier structure, but it's no longer 127 bits of fingerprint, AFAIK)
but just in case: why don't you shrink the fingerprint part to 64 or 80
bits. Then you can use the high 48 or 64 bits in a DNS-compatible
manner.

> I couldn't understand that.  Could you please explain?

It's like pointing to something in a dark room. The action seems valid
but the result is disappointing.  :-)

With today's FQDNs and IP addresses there is a fairly simple
relationship: each can map to the other. With FQDNs, HIP identifiers and
locators this gets a bit complicated. I really think the FQDN is the
actual identifier here, not the HIP id. (But I don't think it serves
much of a purpose to duke this out.)

> So you want me to come up with a completely worked out solution?

Could you?  :-)

> multi-homing, other solutions are needed for that.

Agree. HIP is good if you're on a single host and need the security. We
still need other stuff.

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 17 Mar 2003 16:15:24 -0800

> nodes don't cooperate and don't follow the protocol?

You just take a different hash (or a different part
of an hash), and try again.  Or something like that,
it's been a few months since I read the DHT papers,
and I don't remember the details any more.

> piles of data that lacks a hierarchical structure simply doesn't scale.

Yes it does, if the data is randomly distributed.

If it is hierarchical, you can use a tree structure.
If it is randomly distributed, you can use a hash structure.

The trick is how you distribute your hash structure.
We know how to distrubute a tree structures.  Distributed
hash tables is exactly the method for distributing hash
structures.  (Sorry that I can't be more specific or write
a tutorial, but the DHT stuff is too new for me, too.)

> bits. Then you can use the high 48 or 64 bits in a DNS-compatible

It's there:

    There are two formats for HIT.  These two formats are designed to
    avoid the most commonly occurring IPv6 addresses in RFC2373 [3].
    Bits 0 and 1 are used to differentiate the formats.  If Bit 0 is zero
    and Bit 1 is one, then the rest of HIT is a 126 bits of a SHA-1 hash
    of the Host Identity. If Bit 0 is one and Bit 1 is zero, then the
    next 62 bits is the Host Assigning Authority (HAA) field, and only
    the last 64 bits come from a SHA-1 hash of the Host Identity.  This
    format for HIT is recommended for 'well known' systems.  It is
    possible to support a resolution mechanism for these names in
    directories like DNS. Another use of HAA is in policy controls.

> I really think the FQDN is the
> actual identifier here, not the HIP id. 

There we have the difference.  Computers don't understand names.
Names are just bit strings to them.  Public keys make *re*cognition
possible to computers, just like faces make it to people.

--Pekka Nikander

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Mar 2003 16:33:05 -0800

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Pekka" == Pekka Savola <[email-masked]> writes:
    Pekka> However, my complaint with HIP model is that it seems so closely
    Pekka> tied to 
    Pekka> ESP and security.  

  Why is this a problem for you?

  I think that we very much need better security. This is end-to-end
security. P4s don't even notice doing 3DES (let alone AES), and TPCA may
put hardware accelerators on every motherboard.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Mar 2003 05:19:40 +0200 (EET)

>   Why is this a problem for you?

Two words: Middleboxes, policy. 

Yeah, those are something that security hackers aren't concerned about..

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 Mar 2003 09:50:19 +0100 (CET)

On Mon, 17 Mar 2003, Michael Richardson wrote:

>     Pekka> tied to ESP and security.

>   Why is this a problem for you?

I can't speak for anyone else, but there are many times I have no need
to obfuscate my communications. In those cases, why should I suffer the
bandwidth, CPU and management overhead of IPsec? (In IPv6 everything
will configure pretty much automatically but doing IPsec of course fully
negates (and more) this advantage.)

> put hardware accelerators on every motherboard.

This is hardly true: 3DES maxes out at around 200 Mbps if we are to
believe http://www.mediacrypt.com/engl/Downloads/IDEA_Perf_Overall.pdf

In high speed networking, every copy cycle hurts. So how can encryption
be "free"? Also, even if I have a P4 at my disposal (which I don't) I
could very well need the CPU time for something else. And on mobile
devices, this eats up battery power unnecessarily.

There is often a need for crypto. However, there is also often a need to
_not_ have crypto.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 Mar 2003 10:09:27 +0100 (CET)

> of an hash), and try again.

Hm, this means that there must be a record with a cryptographic
signature for every possible entry, including non-existing ones so a
node can't fake a "doesn't exist" message. But I still don't like the
idea of having to depend on some random servers somewhere on the net
that I have no influence over.

> If it is randomly distributed, you can use a hash structure.

Ok, I should have mentioned some constraints, mostly "distributed". In a
tree, you can delegate sub-trees to organizations. When using a hash (or
a simple flat space that can be searched using binary search) stuff from
different people ends up on one pile so you need some level of trust to
make it work.

> possible to computers, just like faces make it to people.

This is a good comparison. Yes, we recognize people by their face, but a
face is not what identifies a person, that's their name and some extra
info to discriminate against people with the same name.

It is a very useful feature if computers can recognize other computers,
but it's only relevant if they can translate this into something a user
can understand, like: "this message was authenticated as written by
[email-masked]" or "you are now communicating securely with
ietf93registration.ietf.org". In other words: to the user, the
identifier is the FQDN or an application-specific name (usually based on
a FQDN). (But it's ok if there must be some additional mapping between
internal stuff and user stuff.)

---

From: Tim Shepard <[email-masked]>
Date: Tue, 18 Mar 2003 11:39:47 -0500

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

> in conjunction with DNS.  Or something similar.

Today you cannot initiate a connection if all you have is the ssh host
key.  Is this a problem with ssh that needs to be fixed?  If not, then
why does it need to be fixed with HIP?

I also thought I'd mention that you cannot initiate a connection with
a web server if all you have is one of those certificates used to
authenticate the identity of https servers.  But then I realized that
you can, because the dns name of the server is embeded in the
certificate.  The real question is how does anyone ever get their
hands on one of these certificates in the first place?

My real point is that perhaps we do not need to solve this problem.
We can do as ssh does, and start with a DNS name which gets us an IP
address (and perhaps a HIT), then initiate a HIP exchange with
whatever is at that IP address.

(In any case, implementing some sort of DHT as Pekka Nikander suggests
 sounds like a cool idea and an interesting research question.  And
 it may be as easy as he believes.)

			-Tim Shepard
			 [email-masked]

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 18 Mar 2003 08:58:36 -0800

Iljitsch van Beijnum wrote:
> node can't fake a "doesn't exist" message. 

Actually you can do easier by not having a "doesn't exist" message.
If you don't get a reply from the primary server, as resolved
from the primary part of the hash, you just try to secondary
server, resolved from another part of the hash.  There can't be
any correlation between the servers (the hash is basically a
random number, pointing you to random servers).  The probability
of collusion between the servers is very very low, and can
be ignored.  Thus, you don't need to have any signatures for
non-existing ones.

> But I still don't like the

Do you feel the same about MHAP randezvous points?

> different people ends up on one pile so you need some level of trust to

Trust, or random reduncancy.  With random redundancy, you get some
level of byzantine robustness.  Other than that, I agree with you.

>>possible to computers, just like faces make it to people
> 

Agree.  (As with the rest of your comment.)

--Pekka Nikander

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 Mar 2003 17:59:05 +0100 (CET)

> whatever is at that IP address.

That's fine if you're the one initiating the session, but what if you
are on the receiving end? You then get locator IP addresses which may
not have good PTR records (remember, HIP is for mobility too) and a HIP
id that can't be resolved into a name.

>  it may be as easy as he believes.)

Tell me how this can be secure.