Robert,

I started thinking about this again.  Could we rely on kerberos for
security -- i.e. if the portmapper is started with "-k" it can prove
it's identity to the client. Without that it is trusted by clients? 

I assume it has nothing to hide? 

About re-registration: I like the idea of just keeping an open
connection to the portmapper and pinging (why not "binding"?) every
minute or so. 

This is actually a rather nice thing to have, perhaps we should build
it.  Perhaps we should also register the portmapper with IANA
rightaway. 

Peter





Robert Watson writes:
 > 
 > rpcinfo -p localhost gives a good hint as to what to write:
 > 
 > fledge:~> rpcinfo -p localhost
 >    program vers proto   port
 >     100000    2   tcp    111  portmapper
 >     100000    2   udp    111  portmapper
 >     100005    3   udp   1019  mountd
 >     100005    3   tcp   1023  mountd
 >     100005    1   udp   1019  mountd
 >     100005    1   tcp   1023  mountd
 >     100003    2   udp   2049  nfs
 >     100003    3   udp   2049  nfs
 >     100003    2   tcp   2049  nfs
 >     100003    3   tcp   2049  nfs
 >     100024    1   udp   1007  status
 >     100024    1   tcp   1022  status
 > fledge:~> 
 > 
 > Presumably events happen as follows:
 > 
 > 1) Portmapper is loaded at boot and binds to a well known service port,
 > answering RPC2 queries there.
 > 
 > 2) Normal daemons load up, bind a port (either <1024 or not at their
 > choice -- can be a random one or a specific one), and then rpcbind to the
 > portmapper registering in a small runtime database there.  Presumably bind
 > attempts would be accepted only from the localhost -- we might want to use
 > a unix domain socket for security reasons (would allow authorization
 > policy to be determined using file permissions, etc).
 > 
 > The registration process would involve providing a unique service name
 > that the daemon provides -- this unique name space would have to be
 > managed.  We could designate IANA as the handler of this namespace once we
 > have released the RPC2 rfcs, if we so chose.
 > 
 > 3) Incoming connections -- when a client wanted to connect to an RPC2
 > service, it would first bind to the well known portmapper service.  It
 > would send an RPC something like,
 > 
 > port portmap_GetPort(RPC2_Integer service)
 > 
 > We note that portmapper supports both tcp and udp, so perhaps one returns
 > a protocol/port combination.  Similarly, we note that the portmapper also
 > has an ascii name available -- possibly for use in a getservicebyname kind
 > of call.
 > 
 > ..
 > 
 > Some issues of interest:
 > 
 > 1) Security -- how can we secure the portmapper?  Clearly security is an
 > issue -- we need to know that the returned port information is correct.
 > However, the portmapper might be mapping the authentication service;
 > similarly, the portmapper might be a more general function for many
 > possible daemons, in which case how does it authenticate?
 > 
 > 2) Replication hints -- we could have the portmapper "bounce" a service
 > elsewhere by also providing an IP.  This would allow more-transparent
 > replication or forwarding if a service moves.  Right now it isn't a big
 > issue, and Coda provides good replication services, but for other users of
 > RPC2 it might be; similarly, if one has old records for a remote realm,
 > there might be a case for having forwarding.
 > 
 > 3) Daemon stuff -- how can one unregister?  If portmap is restarted, does
 > registry have to occur again?  Perhaps each daemon using the portmapper
 > must maintain an open connection -- they notice when the portmapper goes
 > down, and attempt to reconnect (backing off, etc) and reregister if
 > necessary, and the portmapper notices that they go down and automatically
 > removes their entry if it wasn't deleted by the daemon.
 > 
 > Which brings up deletion -- with an active connection it is fairly easy to
 > manage -- delete on request, or if the connection goes down.  Without an
 > active connection, how do you authenticate deletion requests?  Who is
 > allowed to delete what?  
 > 
 > Just some initial thoughts.  As long as we design it right, the
 > implementation should not be a problem at all.
 > 
 >   Robert N Watson 
 > 
 > Carnegie Mellon University http://www.cmu.edu/
 > SafePort Network Services  http://www.safeport.com/
 > robert@fledge.watson.org   http://www.watson.org/~robert/