Re: Inverse queries on EID; autoconfiguration

wollman@uvm-gen.emba.uvm.edu Mon, 09 August 1993 21:53 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17377; 9 Aug 93 17:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17373; 9 Aug 93 17:53 EDT
Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa05492; 9 Aug 93 17:53 EDT
Received: by thumper.bellcore.com (4.1/4.7) id <AA02255> for ietf-archive@nri.reston.va.us; Mon, 9 Aug 93 17:53:09 EDT
Received: from sadye.emba.uvm.edu by thumper.bellcore.com (4.1/4.7) id <AA02230> for /usr/lib/sendmail -oi -fowner-pip X-pip; Mon, 9 Aug 93 17:53:06 EDT
Received: by sadye.emba.uvm.edu id AA23448 (5.65/1.23); Mon, 9 Aug 93 17:52:06 -0400
Date: Mon, 09 Aug 1993 17:52:06 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: wollman@uvm-gen.emba.uvm.edu
Message-Id: <9308092152.AA23448@sadye.emba.uvm.edu>
To: Paul Francis--formerly Tsuchiya <francis@thumper.bellcore.com>
Cc: pip@thumper.bellcore.com
Subject: Re: Inverse queries on EID; autoconfiguration
In-Reply-To: <9308031631.AA18812@latour.bellcore.com>
References: <9308031631.AA18812@latour.bellcore.com>

<<On Tue, 3 Aug 93 12:31:48 EDT, francis@thumper.bellcore.com (Paul Francis--formerly Tsuchiya) said:

> Sorry I'm late on answering this.  Somehow I overlooked it......

Well, it has taken me quite a while to think up a response to your
answer, so I'll forgive you :-) .

> Clearly a "flat" ID can't be used as effeciently as a hierarchical one
> for inverse lookups.  My hope is that the Pip address would nearly 
> always be carried around with a pip id and therefore inverse lookups
> could usually be done on pip address.

Aha... I had just the opposite hope.  Consider the following practical
consideration...  Under UNIX, information about Pip systems is going
to be communicated between the user and the kernel via a number of
mechanisms, almost all of which involve passing around some flavor of
`struct sockaddr'.  There are parts of both the kernel and user
programs that rely on the fact that that, if two sockaddrs compare
equal, then they refer to the same host.

Taking the concept of the EID to heart, I don't want ``normal''
application programs to ever see the Pip address of any host.  What I
would do is the following:

------------------------------------
Program			Resolver		Kernel
------------------------------------------------------------------------
gethostbyname2(host, 
	       flags)
			Retrieve info from DNS
			Cache addresses, return
			EID back to program.
connect(sock, addr, len)
						Look up EID in
						``routing'' table.
						It's not there.  Send
						RTM_RESOLVE message to
						routing socket listeners.
			Receive RTM_RESOLVE
			on routing socket.
			Send RTM_ADD back to
			kernel with Pip address
			and header fragments.
						Receive RTM_ADD
						message, continue with
						connect() syscall.
						Return OK.
Perform transaction.

------------------------------------
So, you can see, the user program would never see the addressing
information, only the EID.

> I agree that the autoconfiguration of hierarchical IDs isn't that bad, but
> it can be avoided altogether if the IDs are flat.  Also, with flat IDs
> you don't have to worry about changing them when the host joins a new
> organization.

When a ``host joins a new organization'', somebody is going to have to
go in there and update the DNS to reflect that the host has moved from
organization A to organization B.  It's no easier to update the DNS to
stick in an 802 number than it is to update the DNS to stick in the
next number in the organization's assigned ID space; indeed, the
latter can be much more easily automated than the former.

Dynamic updates to the DNS open up a whole new can of security worms
which we really shouldn't be dealing with.

> Also, if the ID has organizational significance, what is the meaning
> of a mobile host temporarily moving to another organization?  Does
> it get a new ID?  Of course it shouldn't, but what if the
> organization is filtering based on ID?

Pip does not, in its present form, provide any mechanism by which this
sort of filtering can be accomplished securely.  Any conceivable
security mechanism which could do this would require setup work
comparable to adding a new ID to a filter expression somewhere anyway.
You get what you pay for...

> The hierarchical ID introduces a number of questions that I didn't
> find easy answers for.....

Fire away, and I'll see if I can't demolish them all (or at least
point out where they are inconsistent).

-GAWollman

--
Garrett A. Wollman   | Shashish is simple, it's discreet, it's brief. ... 
wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance.
uvm-gen!wollman      | It is a bond more powerful than absence.  We like people
UVM disagrees.       | who like Shashish.  - Claude McKenzie + Florent Vollant