Many others have the same sorts of feelings.

I have been thinking about firewalls, nats, and strong
encryption/authentication.  I have a semi-hairbrained scheme which
might work.

Currently venus<>vice uses two pairs of static ports, with 2430<>2432
for control and 2431<>2433 for data, IIRC.  (I only run this under
IPsec ESP now, so I don't see them anymore...)
I realize more or less why rpc2 uses the dual ports (side effects are
on the second set).  This has several bad effects in the modern
nat/firewall world:

  firewalls have trouble reasoning
     2430->2432 out means not only to let in 2430<-2432, but 2431<=2433
     Thus, coda generally doesn't work through even non-nat firewalls

  NAT means that the 2430 is no longer 2430 at the server, and thus
  it's hard to invert the mapping to end up at 2431, without having
  support in the nat implementation.
  
However, I observe that this isn't fundamentally necessary.
With IPsec, I am multiplexing all coda traffic (rpc control, se, and
also auth2) over ESP, so that all the intermediate systems don't see
the port numbers.  One could do something kind of like this within UDP
(and thus make it through the usual udp-replies-allowed firewall).

Basically, the idea is

Munge RPC2 so that it 

  opens a single socket, with a well-known port on servers, and a
  random port on clients

  takes the port numbers it would have used on the outgoing packet,
  and puts them in a new header (basically udp within udp).

  when receiving a packet, splits off the inner header and then
  dispatches the receive to the right place

In addition, if doing this, it would be good to have a serious think
about security features.  I could imagine that venus/vice could take
the rpc2 keys and use GSS-API to wrap the contents, with some outer
header indicating which one key was in use.

This would push coda a bit in the 'kerberos required' direction (when
this mode is in use, or perhaps it's optional), and I realize that
might not seem good.  But kerberos is not that hard to set up compared
to coda :-), and there don't seem to be other good solutions.

I was going to try to think this through more, but I was provoked into
sending this by the recent comments.

        Greg Troxel <gdt_at_ir.bbnf.com>