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
- Inverse queries on EID; autoconfiguration wollman
- Re: Inverse queries on EID; autoconfiguration William Allen Simpson
- Re: Inverse queries on EID; autoconfiguration Paul Francis--formerly Tsuchiya
- Re: Inverse queries on EID; autoconfiguration Bob Smart
- Re: Inverse queries on EID; autoconfiguration wollman
- Re: Inverse queries on EID; autoconfiguration Paul Francis--formerly Tsuchiya
- Re: Inverse queries on EID; autoconfiguration wollman