IP Addressing Problems: on my laptop

[Mark S. Miller]

Answering in reverse order

At 02:49 PM 1/11/99 , shapj@us.ibm.com wrote:
>My sense, in the end, is that you aren't really after an IP address, nor
>even a unique host identifier.  What you *really* seem to be after is a
>unique *session* identifier.  I can imagine running independent sessions on
>a server and wanting to be able to connect to such independently.  Unique
>session identifiers can certainly be built, but it isn't going to come from
>the host.

[-] We have uniqueness.  We need routing.

I'm not sure what you mean by "session" here.  We certainly did first need
a robustly unique identifier, and we've got a great one: the VatID.  Each
Vat, when it is first made communicative ("introducer onTheAir" in the
upcoming 0.8x release), it ensures that it has enough true entropy and then
generates a public/private key pair.  (Currently for DSA, since RSA is
still patented.)  The hash of the public key is the identity of this Vat --
the VatID.

When Alice tells Bob about Carol, in the encoding and decoding of the
message, Alice's Vat is also telling Bob's Vat about Carol's Vat by
communicating Carol's VatID.  When Bob's *somehow* connects to Carol's
alleged Vat, the initial handshake only succeeds if Carol's alleged Vat
demonstrates that it knows the corresponding private key.  The result of
the handshake is a secure (authentication, integrity, secrecy) data pipe
between Bob's Vat and Carol's Vat, all based on shared secrets generated by
the handshake.

The entire remaining problem is a routing problem.  Between Network Address
Translation, firewall restrictions, broken Java caching logic, dynamic IP
address assignment, and Vat migration, Alice is in a difficult position.
She is currently in contact with both Bob and Carol, but her knowledge of
the TCP/IP address she uses to talk to Carol doesn't enable her to know
what to say to Bob in order to enable Bob to contact Carol -- even with the
cooperation of Bob and Carol.  She has a similar problem of figuring out
what to communicate to her future self so she can later re-establish
contact with Carol, since both she and Carol may then be elsewhere in
TCP/IP space.

The VLS was originally conceived to solve the Vat migration and persistence
problem, but it seems it should grow to solve the others routing problems
as well.  Note that VLS misbehavior cannot result in anything worse than
denial of service and resource consumption.  And if *any* of the VLSs on a
search path succeed at routing an introduction, the other's cannot
successfully even deny service.


>It was never the case that an IP address mapped to a host.  It was rather
>the case that an IP address mapped to a host *interface*.

[#] Java's networking API has no notion of host interface vs host.
As far as I can tell.


>To work around this, the CNAME (canonical name) entry was added to DNS.  In
>theory, you are supposed to run reverse DNS on IP number w.x.y.z by doing a
>DNS lookup on z.y.x.w.in-addr.arpa, examine the CNAME record, and thereby
>obtain the host name.
>
>Please note, however, that at no time did CNAME give you anything better
>than the *alleged* host name in practice.

[+] Alleged is fine, since security comes from the VatID.


>Further, please note that the trend in web server functionality has been to
>completely divorce host name from IP address.  In newer web clients, for
>example, a.com and b.com may actually be mapped to the same IP address.
>The client provides the name of the host in the protocol exchange, and the
>web server uses this for virtual hosting.

[?] What are the implications of this for E?